Minor changes: tags, typos, updates and other cosmetic changes

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

diff --git a/best-pkging-practices.dbk b/best-pkging-practices.dbk
index 32d5115f885ef7133b7b27c8a5a2e3d6f37e432d..ca9f149c9d8eed0733df213bd95913e1788a184c 100644 (file)
--- a/best-pkging-practices.dbk
+++ b/best-pkging-practices.dbk
@@ -67,7 +67,7 @@ You can get started with <systemitem role="package">debhelper</systemitem> by
 reading <citerefentry> <refentrytitle>debhelper</refentrytitle>
 <manvolnum>1</manvolnum> </citerefentry>, and looking at the examples that come
 with the package.  <command>dh_make</command>, from the <systemitem
 reading <citerefentry> <refentrytitle>debhelper</refentrytitle>
 <manvolnum>1</manvolnum> </citerefentry>, and looking at the examples that come
 with the package.  <command>dh_make</command>, from the <systemitem

-role="package">dh-make</systemitem> package (see <xref linkend="dh-make"/> ),
+role="package">dh-make</systemitem> package (see <xref linkend="dh-make"/>),

 can be used to convert a vanilla source package to a <systemitem
 role="package">debhelper</systemitem>ized package.  This shortcut, though,
 should not convince you that you do not need to bother understanding the
 can be used to convert a vanilla source package to a <systemitem
 role="package">debhelper</systemitem>ized package.  This shortcut, though,
 should not convince you that you do not need to bother understanding the


@@ -225,7 +225,7 @@ repeating the package name, but also informative.
 The synopsis functions as a phrase describing the package, not a complete
 sentence, so sentential punctuation is inappropriate: it does not need extra
 capital letters or a final period (full stop). It should also omit any initial
 The synopsis functions as a phrase describing the package, not a complete
 sentence, so sentential punctuation is inappropriate: it does not need extra
 capital letters or a final period (full stop). It should also omit any initial

-indefinite or definite article - "a", "an", or "the". Thus for instance:
+indefinite or definite article — "a", "an", or "the". Thus for instance:

 </para>
 <screen>
 Package: libeg0
 </para>
 <screen>
 Package: libeg0


@@ -233,8 +233,8 @@ Description: exemplification support library
 </screen>
 <para>
 Technically this is a noun phrase minus articles, as opposed to a verb phrase.
 </screen>
 <para>
 Technically this is a noun phrase minus articles, as opposed to a verb phrase.

-A good heuristic is that it should be possible to substitute the package name
-and synopsis into this formula:
+A good heuristic is that it should be possible to substitute the package
+<replaceable>name</replaceable> and <replaceable>synopsis</replaceable> into this formula:

 </para>
 <para>
 The package <replaceable>name</replaceable> provides {a,an,the,some}
 </para>
 <para>
 The package <replaceable>name</replaceable> provides {a,an,the,some}


@@ -482,7 +482,7 @@ file.
 <para>
 The only bugs closed with a changelog entry should be those that are actually
 fixed in the same package revision.  Closing unrelated bugs in the changelog is
 <para>
 The only bugs closed with a changelog entry should be those that are actually
 fixed in the same package revision.  Closing unrelated bugs in the changelog is

-bad practice.  See <xref linkend="upload-bugfix"/> .
+bad practice.  See <xref linkend="upload-bugfix"/>.

 </para>
 <para>
 The changelog entries should <emphasis role="strong">not</emphasis> be used for
 </para>
 <para>
 The changelog entries should <emphasis role="strong">not</emphasis> be used for


@@ -563,15 +563,15 @@ inserting the title of each different bug.
 </section>
 
 <section id="bpp-news-debian">
 </section>
 
 <section id="bpp-news-debian">

-<title>Supplementing changelogs with NEWS.Debian files</title>
+<title>Supplementing changelogs with <filename>NEWS.Debian</filename> files</title>

 <para>
 <para>

-Important news about changes in a package can also be put in <filename>
-NEWS.Debian</filename> files.
+Important news about changes in a package can also be put in
+<filename>NEWS.Debian</filename> files.

 The news will be displayed by tools like apt-listchanges, before all the rest
 of the changelogs.  This is the preferred means to let the user know about
 significant changes in a package.  It is better than using debconf notes since
 The news will be displayed by tools like apt-listchanges, before all the rest
 of the changelogs.  This is the preferred means to let the user know about
 significant changes in a package.  It is better than using debconf notes since

-it is less annoying and the user can go back and refer to the <filename>
-NEWS.Debian</filename> file after the install.  And it's better than listing
+it is less annoying and the user can go back and refer to the
+<filename>NEWS.Debian</filename> file after the install.  And it's better than listing

 major changes in <filename>README.Debian</filename>, since the user can easily
 miss such notes.
 </para>
 major changes in <filename>README.Debian</filename>, since the user can easily
 miss such notes.
 </para>


@@ -581,8 +581,8 @@ asterisks and describe each news item with a full paragraph when necessary
 rather than the more concise summaries that would go in a changelog.  It's a
 good idea to run your file through <literal>dpkg-parsechangelog</literal> to
 check its formatting as it will not be automatically checked during build as
 rather than the more concise summaries that would go in a changelog.  It's a
 good idea to run your file through <literal>dpkg-parsechangelog</literal> to
 check its formatting as it will not be automatically checked during build as

-the changelog is.  Here is an example of a real <filename>NEWS.Debian
-</filename> file:
+the changelog is.  Here is an example of a real
+<filename>NEWS.Debian</filename> file:

 </para>
 <screen>
 cron (3.0pl1-74) unstable; urgency=low
 </para>
 <screen>
 cron (3.0pl1-74) unstable; urgency=low


@@ -595,11 +595,11 @@ cron (3.0pl1-74) unstable; urgency=low
  -- Steve Greenland &lt;stevegr@debian.org&gt;  Sat,  6 Sep 2003 17:15:03 -0500
 </screen>
 <para>
  -- Steve Greenland &lt;stevegr@debian.org&gt;  Sat,  6 Sep 2003 17:15:03 -0500
 </screen>
 <para>

-The <filename>NEWS.Debian</filename> file is installed as <filename>
-/usr/share/doc/<replaceable>package</replaceable>/NEWS.Debian.gz</filename>.
+The <filename>NEWS.Debian</filename> file is installed as
+<filename>/usr/share/doc/<replaceable>package</replaceable>/NEWS.Debian.gz</filename>.

 It is compressed, and always has that name even in Debian native packages.
 It is compressed, and always has that name even in Debian native packages.

-If you use <literal>debhelper</literal>, <literal>dh_installchangelogs
-</literal> will install <filename>debian/NEWS</filename> files for you.
+If you use <literal>debhelper</literal>, <literal>dh_installchangelogs</literal>
+will install <filename>debian/NEWS</filename> files for you.

 </para>
 <para>
 Unlike changelog files, you need not update <filename>NEWS.Debian</filename>
 </para>
 <para>
 Unlike changelog files, you need not update <filename>NEWS.Debian</filename>


@@ -673,7 +673,7 @@ the following POSIX-compliant shell function may help:
 </para>
 &example-pathfind;
 <para>
 </para>
 &example-pathfind;
 <para>

-You can use this function to search <literal>$PATH</literal> for a command
+You can use this function to search <varname>$PATH</varname> for a command

 name, passed as an argument.  It returns true (zero) if the command was found,
 and false if not.  This is really the most portable way, since <literal>command
 -v</literal>, <command>type</command>, and <command>which</command> are not
 name, passed as an argument.  It returns true (zero) if the command was found,
 and false if not.  This is really the most portable way, since <literal>command
 -v</literal>, <command>type</command>, and <command>which</command> are not


@@ -721,7 +721,7 @@ need of answering a wide bunch of questions before getting any little thing
 installed.
 </para>
 <para>
 installed.
 </para>
 <para>

-Keep usage notes to what they belong: the NEWS.Debian, or README.Debian file.
+Keep usage notes to what they belong: the <filename>NEWS.Debian</filename>, or <filename>README.Debian</filename> file.

 Only use notes for important notes which may directly affect the package
 usability.  Remember that notes will always block the install until confirmed
 or bother the user by email.
 Only use notes for important notes which may directly affect the package
 usability.  Remember that notes will always block the install until confirmed
 or bother the user by email.


@@ -747,7 +747,7 @@ Please use (and abuse) &email-debian-l10n-english; mailing
 list.  Have your templates proofread.
 </para>
 <para>
 list.  Have your templates proofread.
 </para>
 <para>

-Badly written templates give a poor image of your package, of your work...or
+Badly written templates give a poor image of your package, of your work... or

 even of Debian itself.
 </para>
 <para>
 even of Debian itself.
 </para>
 <para>


@@ -768,7 +768,7 @@ translated by translation teams or even individuals.
 <para>
 Please use gettext-based templates.  Install <systemitem
 role="package">po-debconf</systemitem> on your development system and read its
 <para>
 Please use gettext-based templates.  Install <systemitem
 role="package">po-debconf</systemitem> on your development system and read its

-documentation (<literal>man po-debconf</literal> is a good start).
+documentation (<command>man po-debconf</command> is a good start).

 </para>
 <para>
 Avoid changing templates too often.  Changing templates text induces more work
 </para>
 <para>
 Avoid changing templates too often.  Changing templates text induces more work


@@ -782,26 +782,26 @@ enough, the original translation is kept in PO files but marked as
 If you plan to do changes
 to your original templates, please use the notification system provided with
 the <systemitem
 If you plan to do changes
 to your original templates, please use the notification system provided with
 the <systemitem

-role="package">po-debconf</systemitem> package, namely the <command>
-podebconf-report-po</command>, to contact translators.  Most active
+role="package">po-debconf</systemitem> package, namely the 
+<command>podebconf-report-po</command>, to contact translators.  Most active

 translators are very responsive and getting their work included along with your
 modified templates will save you additional uploads.  If you use gettext-based
 templates, the translator's name and e-mail addresses are mentioned in the PO
 translators are very responsive and getting their work included along with your
 modified templates will save you additional uploads.  If you use gettext-based
 templates, the translator's name and e-mail addresses are mentioned in the PO

-files headers and will be used by <command>
-podebconf-report-po</command>.
+files headers and will be used by
+<command>podebconf-report-po</command>.

 </para>
 <para>
 A recommended use of that utility is:
 </para>
 </para>
 <para>
 A recommended use of that utility is:
 </para>

-<programlisting>cd debian/po &amp;&amp; podebconf-report-po --languageteam --withtranslators --call --deadline="+10 days"</programlisting>
+<programlisting>cd debian/po &amp;&amp; podebconf-report-po --call --languageteam --withtranslators --deadline="+10 days"</programlisting>

 <para>
 <para>

-This command will first synchronize the PO and POT files in debian/po with
+This command will first synchronize the PO and POT files in <filename>debian/po</filename> with

 the templates files listed in <filename>debian/po/POTFILES.in</filename>.
 the templates files listed in <filename>debian/po/POTFILES.in</filename>.

-Then, it will send a call for translation updates to the language team
+Then, it will send a call for new translations, in the &email-debian-i18n; mailing
+list. Finally, it will also send a call for translation updates to the language team

 (mentioned in the <literal>Language-Team</literal> field of each PO file)
 as well as the last translator (mentioned in
 (mentioned in the <literal>Language-Team</literal> field of each PO file)
 as well as the last translator (mentioned in

-<literal>Last-translator</literal>). Finally, it will also send a call for
-new translations, in the &email-debian-i18n; mailing list.
+<literal>Last-translator</literal>).

 </para>
 <para>
 Giving a deadline to translators is always appreciated, so that they can
 </para>
 <para>
 Giving a deadline to translators is always appreciated, so that they can


@@ -841,11 +841,10 @@ strings.
 <orderedlist numeration="arabic">
 <listitem>
 <para>
 <orderedlist numeration="arabic">
 <listitem>
 <para>

-Try finding a complete translation file <emphasis role="strong"> before</emphasis>
+Try finding a complete translation file <emphasis role="strong">before</emphasis>

 the change:
 </para>
 the change:
 </para>

-<programlisting>for i in debian/po/*po; do echo -n $i: ; msgfmt -o /dev/null
---statistics $i; done</programlisting>
+<programlisting>for i in debian/po/*po; do echo -n $i: ; msgfmt -o /dev/null --statistics $i; done</programlisting>

 <para>
 The file only showing <emphasis>translated</emphasis> items will be used
 as the reference file. If there is none (which should not happen if you take
 <para>
 The file only showing <emphasis>translated</emphasis> items will be used
 as the reference file. If there is none (which should not happen if you take


@@ -873,7 +872,7 @@ change in punctuation, for instance.
 <para>
 Modify all PO files by using <command>sed</command>. The use of that command
 is recommended over any text editor to guarantee that the files encoding will
 <para>
 Modify all PO files by using <command>sed</command>. The use of that command
 is recommended over any text editor to guarantee that the files encoding will

-not be broken by the edit action.
+not be broken by the edit action:

 </para>
 <programlisting>
 cd debian/po
 </para>
 <programlisting>
 cd debian/po


@@ -887,7 +886,7 @@ Change the debconf template file to fix the typo.
 </listitem>
 <listitem>
 <para>
 </listitem>
 <listitem>
 <para>

-Run <command>debconf-updatepo</command>
+Run <command>debconf-updatepo</command>.

 </para>
 </listitem>
 <listitem>
 </para>
 </listitem>
 <listitem>


@@ -900,8 +899,10 @@ msgfmt -o /dev/null --statistics debian/po/foo.po
 </programlisting>
 </listitem>
 <listitem>
 </programlisting>
 </listitem>
 <listitem>

+<para>

 If the file's statistics changed, you did something wrong. Try again
 or ask for help on the &email-debian-i18n; mailing list.
 If the file's statistics changed, you did something wrong. Try again
 or ask for help on the &email-debian-i18n; mailing list.

+</para>

 </listitem>
 </orderedlist>
 <para>
 </listitem>
 </orderedlist>
 <para>


@@ -914,43 +915,42 @@ Put all incomplete PO files out of the way.  You can check the completeness by
 using (needs the <systemitem role="package">gettext</systemitem> package
 installed):
 </para>
 using (needs the <systemitem role="package">gettext</systemitem> package
 installed):
 </para>

-<programlisting>for i in debian/po/*po; do echo -n $i: ; msgfmt -o /dev/null
---statistics $i; done</programlisting>
+<programlisting>for i in debian/po/*po; do echo -n $i: ; msgfmt -o /dev/null --statistics $i; done</programlisting>

 </listitem>
 <listitem>
 <para>
 </listitem>
 <listitem>
 <para>

-move all files which report either fuzzy strings to a temporary place.  Files
+Move all files which report either fuzzy strings to a temporary place.  Files

 which report no fuzzy strings (only translated and untranslated) will be kept
 in place.
 </para>
 </listitem>
 <listitem>
 <para>
 which report no fuzzy strings (only translated and untranslated) will be kept
 in place.
 </para>
 </listitem>
 <listitem>
 <para>

-now <emphasis role="strong">and now only</emphasis>, modify the template for
+Now <emphasis role="strong">and now only</emphasis>, modify the template for

 the typos and check again that translation are not impacted (typos, spelling
 the typos and check again that translation are not impacted (typos, spelling

-errors, sometimes typographical corrections are usually OK)
+errors, sometimes typographical corrections are usually OK).

 </para>
 </listitem>
 <listitem>
 <para>
 </para>
 </listitem>
 <listitem>
 <para>

-run <command>debconf-updatepo</command>.  This will fuzzy all strings you
-modified in translations.  You can see this by running the above again
+Run <command>debconf-updatepo</command>.  This will fuzzy all strings you
+modified in translations.  You can see this by running the above again.

 </para>
 </listitem>
 <listitem>
 <para>
 </para>
 </listitem>
 <listitem>
 <para>

-use the following command:
+Use the following command:

 </para>
 <programlisting>for i in debian/po/*po; do msgattrib --output-file=$i --clear-fuzzy $i; done</programlisting>
 </listitem>
 <listitem>
 <para>
 </para>
 <programlisting>for i in debian/po/*po; do msgattrib --output-file=$i --clear-fuzzy $i; done</programlisting>
 </listitem>
 <listitem>
 <para>

-move back to debian/po the files which showed fuzzy strings in the first step
+Move back to <filename>debian/po</filename> the files which showed fuzzy strings in the first step.

 </para>
 </listitem>
 <listitem>
 <para>
 </para>
 </listitem>
 <listitem>
 <para>

-run <command>debconf-updatepo</command> again
+Run <command>debconf-updatepo</command> again.

 </para>
 </listitem>
 </orderedlist>
 </para>
 </listitem>
 </orderedlist>


@@ -1007,14 +1007,14 @@ This part gives some information which is mostly taken from the <citerefentry>
 <section id="s6.5.3.1">
 <title>Type</title>
 <section id="s6.5.3.1.1">
 <section id="s6.5.3.1">
 <title>Type</title>
 <section id="s6.5.3.1.1">

-<title>string:</title>
+<title>string</title>

 <para>
 Results in a free-form input field that the user can type any string into.
 </para>
 </section>
 
 <section id="s6.5.3.1.2">
 <para>
 Results in a free-form input field that the user can type any string into.
 </para>
 </section>
 
 <section id="s6.5.3.1.2">

-<title>password:</title>
+<title>password</title>

 <para>
 Prompts the user for a password.  Use this with caution; be aware that the
 password the user enters will be written to debconf's database.  You should
 <para>
 Prompts the user for a password.  Use this with caution; be aware that the
 password the user enters will be written to debconf's database.  You should


@@ -1023,7 +1023,7 @@ probably clean that value out of the database as soon as is possible.
 </section>
 
 <section id="s6.5.3.1.3">
 </section>
 
 <section id="s6.5.3.1.3">

-<title>boolean:</title>
+<title>boolean</title>

 <para>
 A true/false choice.  Remember: true/false, <emphasis role="strong">not
 yes/no</emphasis>...
 <para>
 A true/false choice.  Remember: true/false, <emphasis role="strong">not
 yes/no</emphasis>...


@@ -1031,7 +1031,7 @@ yes/no</emphasis>...
 </section>
 
 <section id="s6.5.3.1.4">
 </section>
 
 <section id="s6.5.3.1.4">

-<title>select:</title>
+<title>select</title>

 <para>
 A choice between one of a number of values.  The choices must be specified in a
 field named 'Choices'.  Separate the possible values with commas and spaces,
 <para>
 A choice between one of a number of values.  The choices must be specified in a
 field named 'Choices'.  Separate the possible values with commas and spaces,


@@ -1069,7 +1069,7 @@ The debconf templates flag system offers many such possibilities. The
 </section>
 
 <section id="s6.5.3.1.5">
 </section>
 
 <section id="s6.5.3.1.5">

-<title>multiselect:</title>
+<title>multiselect</title>

 <para>
 Like the select data type, except the user can choose any number of items from
 the choices list (or chose none of them).
 <para>
 Like the select data type, except the user can choose any number of items from
 the choices list (or chose none of them).


@@ -1077,7 +1077,7 @@ the choices list (or chose none of them).
 </section>
 
 <section id="s6.5.3.1.6">
 </section>
 
 <section id="s6.5.3.1.6">

-<title>note:</title>
+<title>note</title>

 <para>
 Rather than being a question per se, this datatype indicates a note that can be
 displayed to the user.  It should be used only for important notes that the
 <para>
 Rather than being a question per se, this datatype indicates a note that can be
 displayed to the user.  It should be used only for important notes that the


@@ -1088,14 +1088,14 @@ note to them in some cases.
 </section>
 
 <section id="s6.5.3.1.7">
 </section>
 
 <section id="s6.5.3.1.7">

-<title>text:</title>
+<title>text</title>

 <para>
 This type is now considered obsolete: don't use it.
 </para>
 </section>
 
 <section id="s6.5.3.1.8">
 <para>
 This type is now considered obsolete: don't use it.
 </para>
 </section>
 
 <section id="s6.5.3.1.8">

-<title>error:</title>
+<title>error</title>

 <para>
 This type is designed to handle error messages.  It is mostly similar to the
 note type.  Frontends may present it differently (for instance, the dialog
 <para>
 This type is designed to handle error messages.  It is mostly similar to the
 note type.  Frontends may present it differently (for instance, the dialog


@@ -1162,7 +1162,7 @@ read below.
 <section id="s6.5.3.3">
 <title>Choices</title>
 <para>
 <section id="s6.5.3.3">
 <title>Choices</title>
 <para>

-This field should be used for Select and Multiselect types.  It contains the
+This field should be used for select and multiselect types.  It contains the

 possible choices which will be presented to users.  These choices should be
 separated by commas.
 </para>
 possible choices which will be presented to users.  These choices should be
 separated by commas.
 </para>


@@ -1263,7 +1263,7 @@ the interface often makes this clear).
 <itemizedlist>
 <listitem>
 <para>
 <itemizedlist>
 <listitem>
 <para>

-The short description should be considered to be a *title*.
+The short description should be considered to be a <emphasis role="strong">title</emphasis>.

 </para>
 </listitem>
 <listitem>
 </para>
 </listitem>
 <listitem>


@@ -1276,10 +1276,10 @@ explanation of the note.  Phrases, no terse writing style.
 <para>
 <emphasis role="strong">Do not abuse debconf.</emphasis> Notes are the most
 common way to abuse debconf.  As written in debconf-devel manual page: it's
 <para>
 <emphasis role="strong">Do not abuse debconf.</emphasis> Notes are the most
 common way to abuse debconf.  As written in debconf-devel manual page: it's

-best to use them only for warning about very serious problems.  The NEWS.Debian
-or README.Debian files are the appropriate location for a lot of notes.  If, by
+best to use them only for warning about very serious problems.  The <filename>NEWS.Debian</filename>
+or <filename>README.Debian</filename> files are the appropriate location for a lot of notes.  If, by

 reading this, you consider converting your Note type templates to entries in
 reading this, you consider converting your Note type templates to entries in

-NEWS/Debian or README.Debian, plus consider keeping existing translations for
+<filename>NEWS.Debian</filename> or <filename>README.Debian</filename>, plus consider keeping existing translations for

 the future.
 </para>
 </listitem>
 the future.
 </para>
 </listitem>


@@ -1302,7 +1302,7 @@ considerably help translators for doing their work.
 <para>
 If the default value, for a select template, is likely to vary depending on the
 user language (for instance, if the choice is a language choice), please use
 <para>
 If the default value, for a select template, is likely to vary depending on the
 user language (for instance, if the choice is a language choice), please use

-the _DefaultChoice trick.
+the _Default trick.

 </para>
 <para>
 This special field allow translators to put the most appropriate choice
 </para>
 <para>
 This special field allow translators to put the most appropriate choice


@@ -1319,9 +1319,9 @@ Type: select
 __Choices: Afrikaans (af), Bulgarian (bg), Catalan (ca), Chinese (zh), Czech (cs), Danish (da), Dutch (nl), English (en), Esperanto (eo), Estonian (et), Finnish (fi), French (fr), German (de), Hebrew (he), Icelandic (is), Italian (it), Latvian (lv), Norwegian (no), Polish (pl), Portuguese (pt), Romanian (ro), Russian (ru), Spanish (es), Swedish (sv)
 # This is the default choice. Translators may put their own language here
 # instead of the default.
 __Choices: Afrikaans (af), Bulgarian (bg), Catalan (ca), Chinese (zh), Czech (cs), Danish (da), Dutch (nl), English (en), Esperanto (eo), Estonian (et), Finnish (fi), French (fr), German (de), Hebrew (he), Icelandic (is), Italian (it), Latvian (lv), Norwegian (no), Polish (pl), Portuguese (pt), Romanian (ro), Russian (ru), Spanish (es), Swedish (sv)
 # This is the default choice. Translators may put their own language here
 # instead of the default.

-# WARNING : you MUST use the ENGLISH FORM of your language
+# WARNING : you MUST use the ENGLISH NAME of your language

 # For instance, the french translator will need to put French (fr) here.
 # For instance, the french translator will need to put French (fr) here.

-_DefaultChoice: English (en)[ translators, please see comment in PO files]
+_Default: English[ translators, please see comment in PO files]

 _Description: Geneweb default language:
 </screen>
 <para>
 _Description: Geneweb default language:
 </screen>
 <para>


@@ -1330,7 +1330,7 @@ note the use of comments which will show up in files the translators will work
 with.
 </para>
 <para>
 with.
 </para>
 <para>

-The comments are needed as the DefaultChoice trick is a bit confusing: the
+The comments are needed as the _Default trick is a bit confusing: the

 translators may put their own choice
 </para>
 </section>
 translators may put their own choice
 </para>
 </section>


@@ -1343,12 +1343,12 @@ not use Default at all.
 </para>
 <para>
 If you use po-debconf (and you <emphasis role="strong">should</emphasis>, see
 </para>
 <para>
 If you use po-debconf (and you <emphasis role="strong">should</emphasis>, see

-2.2), consider making this field translatable, if you think it may be
+<xref linkend="s6.5.2.2"/>), consider making this field translatable, if you think it may be

 translated.
 </para>
 <para>
 If the default value may vary depending on language/country (for instance the
 translated.
 </para>
 <para>
 If the default value may vary depending on language/country (for instance the

-default value for a language choice), consider using the special _DefaultChoice
+default value for a language choice), consider using the special _Default

 type documented in <citerefentry> <refentrytitle>po-debconf</refentrytitle>
 <manvolnum>7</manvolnum> </citerefentry>).
 </para>
 type documented in <citerefentry> <refentrytitle>po-debconf</refentrytitle>
 <manvolnum>7</manvolnum> </citerefentry>).
 </para>


@@ -1380,7 +1380,7 @@ easier both for maintainer and translators; transition scripts are provided.
 </para>
 <para>
 Using <systemitem role="package">po-debconf</systemitem>, the translation is
 </para>
 <para>
 Using <systemitem role="package">po-debconf</systemitem>, the translation is

-stored in <filename>po</filename> files (drawing from
+stored in <filename>.po</filename> files (drawing from

 <command>gettext</command> translation techniques).  Special template files
 contain the original messages and mark which fields are translatable.  When you
 change the value of a translatable field, by calling
 <command>gettext</command> translation techniques).  Special template files
 contain the original messages and mark which fields are translatable.  When you
 change the value of a translatable field, by calling


@@ -1402,18 +1402,18 @@ There's no way to eliminate all that work, but you can make things easier for
 translators.
 </para>
 <para>
 translators.
 </para>
 <para>

-If you maintain documentation of any size, its easier for translators if they
+If you maintain documentation of any size, it is easier for translators if they

 have access to a source control system.  That lets translators see the
 differences between two versions of the documentation, so, for instance, they
 can see what needs to be retranslated.  It is recommended that the translated
 documentation maintain a note about what source control revision the
 translation is based on.  An interesting system is provided by <ulink
 url="&url-i18n-doc-check;">doc-check</ulink> in the
 have access to a source control system.  That lets translators see the
 differences between two versions of the documentation, so, for instance, they
 can see what needs to be retranslated.  It is recommended that the translated
 documentation maintain a note about what source control revision the
 translation is based on.  An interesting system is provided by <ulink
 url="&url-i18n-doc-check;">doc-check</ulink> in the

-<systemitem role="package">boot-floppies</systemitem> package, which shows an
+<systemitem role="package">debian-installer</systemitem> package, which shows an

 overview of the translation status for any given language, using structured
 comments for the current revision of the file to be translated and, for a
 translated file, the revision of the original file the translation is based on.
 overview of the translation status for any given language, using structured
 comments for the current revision of the file to be translated and, for a
 translated file, the revision of the original file the translation is based on.

-You might wish to adapt and provide that in your CVS area.
+You might wish to adapt and provide that in your VCS area.

 </para>
 <para>
 If you maintain XML or SGML documentation, we suggest that you isolate any
 </para>
 <para>
 If you maintain XML or SGML documentation, we suggest that you isolate any


@@ -1501,8 +1501,8 @@ upstream.
 The manpages do not need to be written directly in the troff format.  Popular
 source formats are Docbook, POD and reST, which can be converted using
 <command>xsltproc</command>, <command>pod2man</command> and
 The manpages do not need to be written directly in the troff format.  Popular
 source formats are Docbook, POD and reST, which can be converted using
 <command>xsltproc</command>, <command>pod2man</command> and

-<command>rst2man</command> respectively. To a lesser extent, the <command>
-help2man</command>program can also be used to write a stub.
+<command>rst2man</command> respectively. To a lesser extent, the
+<command>help2man</command> program can also be used to write a stub.

 </para>
 </section>
 
 </para>
 </section>
 


@@ -1599,13 +1599,13 @@ to keep it all in a single package.
 </para>
 <para>
 However, if the size of the data is considerable, consider splitting it out
 </para>
 <para>
 However, if the size of the data is considerable, consider splitting it out

-into a separate, architecture-independent package (_all.deb).  By doing this,
+into a separate, architecture-independent package (<filename>_all.deb</filename>).  By doing this,

 you avoid needless duplication of the same data into eleven or more .debs, one
 per each architecture.  While this adds some extra overhead into the
 <filename>Packages</filename> files, it saves a lot of disk space on Debian
 mirrors.  Separating out architecture-independent data also reduces processing
 time of <command>lintian</command> (see <xref
 you avoid needless duplication of the same data into eleven or more .debs, one
 per each architecture.  While this adds some extra overhead into the
 <filename>Packages</filename> files, it saves a lot of disk space on Debian
 mirrors.  Separating out architecture-independent data also reduces processing
 time of <command>lintian</command> (see <xref

-linkend="tools-lint"/> ) when run over the entire Debian archive.
+linkend="tools-lint"/>) when run over the entire Debian archive.

 </para>
 </section>
 
 </para>
 </section>
 


@@ -1658,7 +1658,7 @@ your short description.  If you are looking for examples, just run:
 </section>
 
 <section id="bpp-origtargz">
 </section>
 
 <section id="bpp-origtargz">

-<title>Best practices for <filename>orig.tar.gz</filename> files</title>
+<title>Best practices for <filename>.orig.tar.{gz,bz2,lzma}</filename> files</title>

 <para>
 There are two kinds of original source tarballs: Pristine source and repackaged
 upstream source.
 <para>
 There are two kinds of original source tarballs: Pristine source and repackaged
 upstream source.


@@ -1667,8 +1667,8 @@ upstream source.
 <title>Pristine source</title>
 <para>
 The defining characteristic of a pristine source tarball is that the
 <title>Pristine source</title>
 <para>
 The defining characteristic of a pristine source tarball is that the

-<literal>.orig.tar.{gz,bz2}</literal> file is byte-for-byte identical to a tarball officially
-distributed by the upstream author.  <footnote><para> We cannot prevent
+<filename>.orig.tar.{gz,bz2,lzma}</filename> file is byte-for-byte identical to a tarball officially
+distributed by the upstream author.<footnote><para> We cannot prevent

 upstream authors from changing the tarball they distribute without also
 incrementing the version number, so there can be no guarantee that a pristine
 tarball is identical to what upstream <emphasis>currently</emphasis>
 upstream authors from changing the tarball they distribute without also
 incrementing the version number, so there can be no guarantee that a pristine
 tarball is identical to what upstream <emphasis>currently</emphasis>


@@ -1677,7 +1677,7 @@ identical to something that upstream once <emphasis>did</emphasis> distribute.
 If a difference arises later (say, if upstream notices that he wasn't using
 maximal compression in his original distribution and then
 re-<command>gzip</command>s it), that's just too bad.  Since there is no good
 If a difference arises later (say, if upstream notices that he wasn't using
 maximal compression in his original distribution and then
 re-<command>gzip</command>s it), that's just too bad.  Since there is no good

-way to upload a new <literal>.orig.tar.{gz,bz2}</literal> for the same version, there is not even any
+way to upload a new <filename>.orig.tar.{gz,bz2,lzma}</filename> for the same version, there is not even any

 point in treating this situation as a bug.  </para> </footnote> This makes it
 possible to use checksums to easily verify that all changes between Debian's
 version and upstream's are contained in the Debian diff.  Also, if the original
 point in treating this situation as a bug.  </para> </footnote> This makes it
 possible to use checksums to easily verify that all changes between Debian's
 version and upstream's are contained in the Debian diff.  Also, if the original


@@ -1697,14 +1697,14 @@ tarballs as pristine source.  Its strategy is equivalent to the following:
 It unpacks the tarball in an empty temporary directory by doing
 </para>
 <screen>
 It unpacks the tarball in an empty temporary directory by doing
 </para>
 <screen>

-zcat path/to/&lt;packagename&gt;_&lt;upstream-version&gt;.orig.tar.gz | tar xf -
+zcat path/to/<replaceable>packagename</replaceable>_<replaceable>upstream-version</replaceable>.orig.tar.gz | tar xf -

 </screen>
 </listitem>
 <listitem>
 <para>
 If, after this, the temporary directory contains nothing but one directory and
 no other files, <command>dpkg-source</command> renames that directory to
 </screen>
 </listitem>
 <listitem>
 <para>
 If, after this, the temporary directory contains nothing but one directory and
 no other files, <command>dpkg-source</command> renames that directory to

-<literal>&lt;packagename&gt;-&lt;upstream-version&gt;(.orig)</literal>.  The
+<filename><replaceable>packagename</replaceable>-<replaceable>upstream-version</replaceable>(.orig)</filename>.  The

 name of the top-level directory in the tarball does not matter, and is
 forgotten.
 </para>
 name of the top-level directory in the tarball does not matter, and is
 forgotten.
 </para>


@@ -1715,7 +1715,7 @@ Otherwise, the upstream tarball must have been packaged without a common
 top-level directory (shame on the upstream author!).  In this case,
 <command>dpkg-source</command> renames the temporary directory
 <emphasis>itself</emphasis> to
 top-level directory (shame on the upstream author!).  In this case,
 <command>dpkg-source</command> renames the temporary directory
 <emphasis>itself</emphasis> to

-<literal>&lt;packagename&gt;-&lt;upstream-version&gt;(.orig)</literal>.
+<filename><replaceable>packagename</replaceable>-<replaceable>upstream-version</replaceable>(.orig)</filename>.

 </para>
 </listitem>
 </orderedlist>
 </para>
 </listitem>
 </orderedlist>


@@ -1731,17 +1731,17 @@ gzipped tar at all, or if upstream's tarball contains non-DFSG-free material
 that you must remove before uploading.
 </para>
 <para>
 that you must remove before uploading.
 </para>
 <para>

-In these cases the developer must construct a suitable <literal>.orig.tar.{gz,bz2}
-</literal> file himself.  We refer to such a tarball as a repackaged upstream 
+In these cases the developer must construct a suitable <filename>.orig.tar.{gz,bz2,lzma}</filename>
+file himself.  We refer to such a tarball as a repackaged upstream 

 source.  Note that a repackaged upstream source is different from a 
 Debian-native package.  A repackaged source still comes with Debian-specific
 source.  Note that a repackaged upstream source is different from a 
 Debian-native package.  A repackaged source still comes with Debian-specific

-changes in a separate <literal>.diff.gz</literal> or <literal>.debian.tar.{gz,bz2}</literal> and still has a version
-number composed of <literal>&lt;upstream-version&gt;</literal> and
-<literal>&lt;debian-revision&gt;</literal>.
+changes in a separate <filename>.diff.gz</filename> or <filename>.debian.tar.{gz,bz2,lzma}</filename>
+and still has a version number composed of <replaceable>upstream-version</replaceable> and
+<replaceable>debian-version</replaceable>.

 </para>
 <para>
 There may be cases where it is desirable to repackage the source even though
 </para>
 <para>
 There may be cases where it is desirable to repackage the source even though

-upstream distributes a <literal>.tar.gz</literal> that could in principle be
+upstream distributes a <filename>.tar.{gz,bz2,lzma}</filename> that could in principle be

 used in its pristine form.  The most obvious is if
 <emphasis>significant</emphasis> space savings can be achieved by recompressing
 the tar archive or by removing genuinely useless cruft from the upstream
 used in its pristine form.  The most obvious is if
 <emphasis>significant</emphasis> space savings can be achieved by recompressing
 the tar archive or by removing genuinely useless cruft from the upstream


@@ -1749,12 +1749,12 @@ archive.  Use your own discretion here, but be prepared to defend your decision
 if you repackage source that could have been pristine.
 </para>
 <para>
 if you repackage source that could have been pristine.
 </para>
 <para>

-A repackaged <literal>.orig.tar.{gz,bz2}</literal>
+A repackaged <filename>.orig.tar.{gz,bz2,lzma}</filename>

 </para>
 <orderedlist numeration="arabic">
 <listitem>
 <para>
 </para>
 <orderedlist numeration="arabic">
 <listitem>
 <para>

-should be documented in the resulting source package.
+<emphasis role="strong">should</emphasis> be documented in the resulting source package.

 Detailed information on how the repackaged source was obtained,
 and on how this can be reproduced should be provided in
 <filename>debian/copyright</filename>.  It is also a good idea to provide a
 Detailed information on how the repackaged source was obtained,
 and on how this can be reproduced should be provided in
 <filename>debian/copyright</filename>.  It is also a good idea to provide a


@@ -1762,19 +1762,19 @@ and on how this can be reproduced should be provided in
 <filename>debian/rules</filename> file that repeats the process, as described
 in the Policy Manual, <ulink
 url="&url-debian-policy;ch-source.html#s-debianrules">Main
 <filename>debian/rules</filename> file that repeats the process, as described
 in the Policy Manual, <ulink
 url="&url-debian-policy;ch-source.html#s-debianrules">Main

-building script: debian/rules</ulink>.
+building script: <filename>debian/rules</filename></ulink>.

 </para>
 </listitem>
 <listitem>
 <para>
 <emphasis role="strong">should not</emphasis> contain any file that does not
 </para>
 </listitem>
 <listitem>
 <para>
 <emphasis role="strong">should not</emphasis> contain any file that does not

-come from the upstream author(s), or whose contents has been changed by you.
-<footnote><para> As a special exception, if the omission of non-free files
+come from the upstream author(s), or whose contents has been changed by
+you.<footnote><para> As a special exception, if the omission of non-free files

 would lead to the source failing to build without assistance from the Debian
 diff, it might be appropriate to instead edit the files, omitting only the
 would lead to the source failing to build without assistance from the Debian
 diff, it might be appropriate to instead edit the files, omitting only the

-non-free parts of them, and/or explain the situation in a README.source
+non-free parts of them, and/or explain the situation in a <filename>README.source</filename>

 file in the root of the source tree.  But in that case please also urge the
 file in the root of the source tree.  But in that case please also urge the

-upstream author to make the non-free components easier seperable from the rest
+upstream author to make the non-free components easier separable from the rest

 of the source.  </para> </footnote>
 </para>
 </listitem>
 of the source.  </para> </footnote>
 </para>
 </listitem>


@@ -1784,7 +1784,7 @@ of the source.  </para> </footnote>
 reasons, preserve the entire building and portablility infrastructure provided
 by the upstream author.  For example, it is not a sufficient reason for
 omitting a file that it is used only when building on MS-DOS.  Similarly, a
 reasons, preserve the entire building and portablility infrastructure provided
 by the upstream author.  For example, it is not a sufficient reason for
 omitting a file that it is used only when building on MS-DOS.  Similarly, a

-Makefile provided by upstream should not be omitted even if the first thing
+<filename>Makefile</filename> provided by upstream should not be omitted even if the first thing

 your <filename>debian/rules</filename> does is to overwrite it by running a
 configure script.
 </para>
 your <filename>debian/rules</filename> does is to overwrite it by running a
 configure script.
 </para>


@@ -1797,7 +1797,7 @@ mirror rather than trying to locate a canonical upstream distribution point).
 <listitem>
 <para>
 <emphasis role="strong">should</emphasis> use
 <listitem>
 <para>
 <emphasis role="strong">should</emphasis> use

-<literal>&lt;packagename&gt;-&lt;upstream-version&gt;.orig</literal> as the
+<filename><replaceable>packagename</replaceable>-<replaceable>upstream-version</replaceable>.orig</filename> as the

 name of the top-level directory in its tarball.  This makes it possible to
 distinguish pristine tarballs from repackaged ones.
 </para>
 name of the top-level directory in its tarball.  This makes it possible to
 distinguish pristine tarballs from repackaged ones.
 </para>


@@ -1831,9 +1831,9 @@ it in its official location).
 <title>Best practices for debug packages</title>
 <para>
 A debug package is a package with a name ending in -dbg, that contains
 <title>Best practices for debug packages</title>
 <para>
 A debug package is a package with a name ending in -dbg, that contains

-additional information that gdb can use.  Since Debian binaries are stripped by
+additional information that <command>gdb</command> can use.  Since Debian binaries are stripped by

 default, debugging information, including function names and line numbers, is
 default, debugging information, including function names and line numbers, is

-otherwise not available when running gdb on Debian binaries.  Debug packages
+otherwise not available when running <command>gdb</command> on Debian binaries.  Debug packages

 allow users who need this additional debugging information to install it,
 without bloating a regular system with the information.
 </para>
 allow users who need this additional debugging information to install it,
 without bloating a regular system with the information.
 </para>


@@ -1850,7 +1850,7 @@ candidates for debug packages.
 <para>
 Some debug packages may contain an entire special debugging build of a library
 or other binary, but most of them can save space and build time by instead
 <para>
 Some debug packages may contain an entire special debugging build of a library
 or other binary, but most of them can save space and build time by instead

-containing separated debugging symbols that gdb can find and load on the fly
+containing separated debugging symbols that <command>gdb</command> can find and load on the fly

 when debugging a program or library.  The convention in Debian is to keep these
 symbols in <filename>/usr/lib/debug/<replaceable>path</replaceable></filename>, where
 <replaceable>path</replaceable> is the path to the executable or library.  For
 when debugging a program or library.  The convention in Debian is to keep these
 symbols in <filename>/usr/lib/debug/<replaceable>path</replaceable></filename>, where
 <replaceable>path</replaceable> is the path to the executable or library.  For


@@ -1860,17 +1860,17 @@ example, debugging symbols for <filename>/usr/bin/foo</filename> go in
 <filename>/usr/lib/debug/usr/lib/libfoo.so.1</filename>.
 </para>
 <para>
 <filename>/usr/lib/debug/usr/lib/libfoo.so.1</filename>.
 </para>
 <para>

-The debugging symbols can be extracted from an object file using <command>
-objcopy --only-keep-debug</command>.  Then the object file can be stripped,
+The debugging symbols can be extracted from an object file using 
+<command>objcopy --only-keep-debug</command>.  Then the object file can be stripped,

 and <command>objcopy --add-gnu-debuglink</command> used to specify the path
 to the debugging symbol file. 
 <citerefentry> <refentrytitle>objcopy</refentrytitle> <manvolnum>1</manvolnum>
 </citerefentry> explains in detail how this works.
 </para>
 <para>
 and <command>objcopy --add-gnu-debuglink</command> used to specify the path
 to the debugging symbol file. 
 <citerefentry> <refentrytitle>objcopy</refentrytitle> <manvolnum>1</manvolnum>
 </citerefentry> explains in detail how this works.
 </para>
 <para>

-The <command>dh_strip</command> command in debhelper supports creating debug
+The <command>dh_strip</command> command in <systemitem role="package">debhelper</systemitem> supports creating debug

 packages, and can take care of using <command>objcopy</command> to separate
 packages, and can take care of using <command>objcopy</command> to separate

-out the debugging symbols for you.  If your package uses debhelper, all you
+out the debugging symbols for you.  If your package uses <systemitem role="package">debhelper</systemitem>, all you

 need to do is call <command>dh_strip --dbg-package=libfoo-dbg</command>, and
 add an entry to <filename>debian/control</filename> for the debug package.
 </para>
 need to do is call <command>dh_strip --dbg-package=libfoo-dbg</command>, and
 add an entry to <filename>debian/control</filename> for the debug package.
 </para>

diff --git a/common.ent b/common.ent
index 3efbc1f2c07cc5c9f4fbd9b3778f7ba4c5f37c60..d041c822a8cddd5d4a0d710a7a9a7af384a30a03 100644 (file)
--- a/common.ent
+++ b/common.ent
@@ -104,7 +104,8 @@
 <!ENTITY url-dmup "http://&www-debian-org;/devel/dmup">
 <!ENTITY url-worldmap "http://&www-debian-org;/devel/developers.loc">
 
 <!ENTITY url-dmup "http://&www-debian-org;/devel/dmup">
 <!ENTITY url-worldmap "http://&www-debian-org;/devel/developers.loc">
 

-<!ENTITY url-i18n-doc-check "http://cvs.debian.org/boot-floppies/documentation/doc-check?rev=HEAD&amp;content-type=text/vnd.viewcvs-markup">
+<!ENTITY url-i18n-l10n "http://people.debian.org/~jfs/debconf6/html/">
+<!ENTITY url-i18n-doc-check "http://svn.debian.org/wsvn/d-i/trunk/manual/scripts/doc-check?op=file">

 
 <!ENTITY url-eg-desc-upstream-info "http://&packages-host;/unstable/web/wml">
 
 
 <!ENTITY url-eg-desc-upstream-info "http://&packages-host;/unstable/web/wml">
 

diff --git a/new-maintainer.dbk b/new-maintainer.dbk
index 5ff7cccd860b5654b05e9d2173c575888f5690b6..cc234495c08031dbff7b8754963af08deb84e7b9 100644 (file)
--- a/new-maintainer.dbk
+++ b/new-maintainer.dbk
@@ -156,7 +156,7 @@ url="&url-rfc2440;">RFC 2440</ulink>.
 <para>
 You need a version 4 key for use in Debian Development.  Your key length must
 be at least 1024 bits; there is no reason to use a smaller key, and doing so
 <para>
 You need a version 4 key for use in Debian Development.  Your key length must
 be at least 1024 bits; there is no reason to use a smaller key, and doing so

-would be much less secure.  <footnote><para> Version 4 keys are keys conforming
+would be much less secure.<footnote><para> Version 4 keys are keys conforming

 to the OpenPGP standard as defined in RFC 2440.  Version 4 is the key type that
 has always been created when using GnuPG.  PGP versions since 5.x also could
 create v4 keys, the other choice having beein pgp 2.6.x compatible v3 keys
 to the OpenPGP standard as defined in RFC 2440.  Version 4 is the key type that
 has always been created when using GnuPG.  PGP versions since 5.x also could
 create v4 keys, the other choice having beein pgp 2.6.x compatible v3 keys

diff --git a/pkgs.dbk b/pkgs.dbk
index 759bb480c366f45b883e938b75357480a6ec5e7f..86d9273e90783fe8d7f407cdbd262d614e105ba6 100644 (file)
--- a/pkgs.dbk
+++ b/pkgs.dbk
@@ -135,7 +135,7 @@ It is conventional that the changelog entry of a package that contains a new
 upstream version of the software looks like this:
 </para>
 <screen>
 upstream version of the software looks like this:
 </para>
 <screen>

-  * new upstream version
+  * New upstream release.

 </screen>
 <para>
 There are tools to help you create entries and finalize the
 </screen>
 <para>
 There are tools to help you create entries and finalize the


@@ -230,12 +230,12 @@ accompanied by another file that contains the changes made by Debian
 </itemizedlist>
 <para>
 For the native packages, the source package includes a Debian source control
 </itemizedlist>
 <para>
 For the native packages, the source package includes a Debian source control

-file (<literal>.dsc</literal>) and the source tarball
-(<literal>.tar.{gz,bz2,lzma}</literal>). A source package of a non-native package
+file (<filename>.dsc</filename>) and the source tarball
+(<filename>.tar.{gz,bz2,lzma}</filename>). A source package of a non-native package

 includes a Debian source control file, the original source tarball
 includes a Debian source control file, the original source tarball

-(<literal>.orig.tar.{gz,bz2,lzma}</literal>) and the Debian changes
-(<literal>.diff.gz</literal> for the source format “1.0” or
-<literal>.debian.tar.{gz,bz2,lzma}</literal> for the source format “3.0 (quilt)”).
+(<filename>.orig.tar.{gz,bz2,lzma}</filename>) and the Debian changes
+(<filename>.diff.gz</filename> for the source format “1.0” or
+<filename>.debian.tar.{gz,bz2,lzma}</filename> for the source format “3.0 (quilt)”).

 </para>
 <para>
 With source format “1.0”, whether a package is native or not was determined
 </para>
 <para>
 With source format “1.0”, whether a package is native or not was determined


@@ -268,7 +268,7 @@ the archive.
 </para>
 <para>
 Please notice that, in non-native packages, permissions on files that are not
 </para>
 <para>
 Please notice that, in non-native packages, permissions on files that are not

-present in the .orig.tar.{gz,bz2,lzma} will not be preserved, as diff does not store file
+present in the <filename>*.orig.tar.{gz,bz2,lzma}</filename> will not be preserved, as diff does not store file

 permissions in the patch. However when using source format “3.0 (quilt)”,
 permissions of files inside the <filename>debian</filename> directory are
 preserved since they are stored in a tar archive.
 permissions in the patch. However when using source format “3.0 (quilt)”,
 permissions of files inside the <filename>debian</filename> directory are
 preserved since they are stored in a tar archive.


@@ -962,7 +962,7 @@ be sure to mention this fact.
 <para>
 Please note that if secrecy is needed you may not upload a fix to
 <literal>unstable</literal> (or
 <para>
 Please note that if secrecy is needed you may not upload a fix to
 <literal>unstable</literal> (or

-anywhere else, such as a public CVS repository).  It is not sufficient to
+anywhere else, such as a public VCS repository).  It is not sufficient to

 obfuscate the details of the change, as the code itself is public, and can (and
 will) be examined by the general public.
 </para>
 obfuscate the details of the change, as the code itself is public, and can (and
 will) be examined by the general public.
 </para>


@@ -1278,8 +1278,8 @@ short summary of the reason for the removal request.
 <replaceable>[architecture list]</replaceable> is optional and only needed
 if the removal request only applies to some architectures, not all. Note
 that the <command>reportbug</command> will create a title conforming
 <replaceable>[architecture list]</replaceable> is optional and only needed
 if the removal request only applies to some architectures, not all. Note
 that the <command>reportbug</command> will create a title conforming

-to these rules when you use it to report a bug against the <literal>
-ftp.debian.org</literal> pseudo-package.
+to these rules when you use it to report a bug against the 
+<literal>ftp.debian.org</literal> pseudo-package.

 </para>
 
 <para>
 </para>
 
 <para>


@@ -1292,13 +1292,13 @@ pending removal requests.
 </para>
 
 <para>
 </para>
 
 <para>

-Note that removals can only be done for the <literal>unstable
-</literal>, <literal>experimental</literal> and <literal>stable
-</literal> distribution.  Packages are not removed from
+Note that removals can only be done for the <literal>unstable</literal>,
+<literal>experimental</literal> and <literal>stable</literal>
+distribution.  Packages are not removed from

 <literal>testing</literal> directly.  Rather, they will be removed
 automatically after the package has been removed from
 <literal>testing</literal> directly.  Rather, they will be removed
 automatically after the package has been removed from

-<literal>unstable</literal> and no package in <literal>testing
-</literal> depends on it.
+<literal>unstable</literal> and no package in
+<literal>testing</literal> depends on it.

 </para>
 <para>
 There is one exception when an explicit removal request is not necessary: If a
 </para>
 <para>
 There is one exception when an explicit removal request is not necessary: If a


@@ -1337,7 +1337,7 @@ the <command>apt-cache</command> program from the <systemitem
 role="package">apt</systemitem> package.  When invoked as <literal>apt-cache
 showpkg <replaceable>package</replaceable></literal>, the program will show
 details for <replaceable>package</replaceable>, including reverse depends.
 role="package">apt</systemitem> package.  When invoked as <literal>apt-cache
 showpkg <replaceable>package</replaceable></literal>, the program will show
 details for <replaceable>package</replaceable>, including reverse depends.

-Other useful programs include <literal>apt-cache rdepends</literal>,
+Other useful programs include <command>apt-cache rdepends</command>,

 <command>apt-rdepends</command>, <command>build-rdeps</command> (in the
 <systemitem role="package">devscripts</systemitem> package) and
 <command>grep-dctrl</command>.  Removal of
 <command>apt-rdepends</command>, <command>build-rdeps</command> (in the
 <systemitem role="package">devscripts</systemitem> package) and
 <command>grep-dctrl</command>.  Removal of


@@ -1379,13 +1379,13 @@ rename their software (or you made a mistake naming your package),
 you should follow a two-step process to rename it. In the first
 step, change the <filename>debian/control</filename> file to
 reflect the new name and to replace, provide and conflict with the
 you should follow a two-step process to rename it. In the first
 step, change the <filename>debian/control</filename> file to
 reflect the new name and to replace, provide and conflict with the

-obsolete package name (see the <ulink url="&url-debian-policy;">
-Debian Policy Manual</ulink> for details).  Please note that you
+obsolete package name (see the <ulink url="&url-debian-policy;">Debian
+Policy Manual</ulink> for details).  Please note that you

 should only add a <literal>Provides</literal> relation if all
 packages depending on the obsolete package name continue to work
 after the renaming. Once you've uploaded the package and the package
 should only add a <literal>Provides</literal> relation if all
 packages depending on the obsolete package name continue to work
 after the renaming. Once you've uploaded the package and the package

-has moved into the archive, file a bug against <literal>
-ftp.debian.org</literal> asking to remove the package with the
+has moved into the archive, file a bug against <literal>ftp.debian.org</literal>
+asking to remove the package with the

 obsolete name (see <xref linkend="removing-pkgs"/>).  Do not forget
 to properly reassign the package's bugs at the same time.
 </para>
 obsolete name (see <xref linkend="removing-pkgs"/>).  Do not forget
 to properly reassign the package's bugs at the same time.
 </para>


@@ -1464,7 +1464,7 @@ more information).
 If you take over an old package, you probably want to be listed as the
 package's official maintainer in the bug system.  This will happen
 automatically once you upload a new version with an updated
 If you take over an old package, you probably want to be listed as the
 package's official maintainer in the bug system.  This will happen
 automatically once you upload a new version with an updated

-<literal>Maintainer:</literal> field, although it can take a few hours after
+<literal>Maintainer</literal> 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 <xref linkend="pkg-tracking-system"/> to get the bug reports.
 However, make sure that the old maintainer has no problem with the fact that
 the upload is done.  If you do not expect to upload a new version for a while,
 you can use <xref linkend="pkg-tracking-system"/> to get the bug reports.
 However, make sure that the old maintainer has no problem with the fact that


@@ -1487,8 +1487,8 @@ Porting is the act of building Debian packages for architectures that 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, when a maintainer
 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, when a maintainer

-uploads a (portable) source packages with binaries for the <literal>i386
-</literal> architecture, it will be built for each of the other architectures,
+uploads a (portable) source packages with binaries for the <literal>i386</literal>
+architecture, it will be built for each of the other architectures,

 amounting to &number-of-arches; more builds.
 </para>
 <section id="kind-to-porters">
 amounting to &number-of-arches; more builds.
 </para>
 <section id="kind-to-porters">


@@ -1592,7 +1592,7 @@ standardize on different compilers.
 </listitem>
 <listitem>
 <para>
 </listitem>
 <listitem>
 <para>

-Make sure your debian/rules contains separate <literal>binary-arch</literal>
+Make sure your <filename>debian/rules</filename> contains separate <literal>binary-arch</literal>

 and <literal>binary-indep</literal> targets, as the Debian Policy Manual
 requires.  Make sure that both targets work independently, that is, that you
 can call the target without having called the other before.  To test this,
 and <literal>binary-indep</literal> targets, as the Debian Policy Manual
 requires.  Make sure that both targets work independently, that is, that you
 can call the target without having called the other before.  To test this,


@@ -1623,8 +1623,8 @@ The way to invoke <command>dpkg-buildpackage</command> is as
 -m<replaceable>porter-email</replaceable></literal>.  Of course, set
 <replaceable>porter-email</replaceable> to your email address.  This will do a
 binary-only build of only the architecture-dependent portions of the package,
 -m<replaceable>porter-email</replaceable></literal>.  Of course, set
 <replaceable>porter-email</replaceable> to your email address.  This will do a
 binary-only build of only the architecture-dependent portions of the package,

-using the <literal>binary-arch</literal> target in <filename>debian/rules
-</filename>.
+using the <literal>binary-arch</literal> target in
+<filename>debian/rules</filename>.

 </para>
 <para>
 If you are working on a Debian machine for your porting efforts and you need to
 </para>
 <para>
 If you are working on a Debian machine for your porting efforts and you need to


@@ -1648,8 +1648,7 @@ version number greater than the currently available one).
 You have to make sure that your binary-only NMU doesn't render the package
 uninstallable.  This could happen when a source package generates
 arch-dependent and arch-independent packages that have inter-dependencies
 You have to make sure that your binary-only NMU doesn't render the package
 uninstallable.  This could happen when a source package generates
 arch-dependent and arch-independent packages that have inter-dependencies

-generated using dpkg's substitution variable <literal>$(Source-Version)
-</literal>.
+generated using dpkg's substitution variable <literal>$(Source-Version)</literal>.

 </para>
 <para>
 Despite the required modification of the changelog, these are called
 </para>
 <para>
 Despite the required modification of the changelog, these are called


@@ -1665,14 +1664,14 @@ source code).
 </para>
 <para>
 The ``magic'' for a recompilation-only NMU is triggered by using a suffix
 </para>
 <para>
 The ``magic'' for a recompilation-only NMU is triggered by using a suffix

-appended to the package version number, following the form <literal>
-b<replaceable>number</replaceable></literal>.
+appended to the package version number, following the form
+<literal>b<replaceable>number</replaceable></literal>.

 For instance, if the latest version you are recompiling against was version
 <literal>2.9-3</literal>, your binary-only NMU should carry a version of
 For instance, if the latest version you are recompiling against was version
 <literal>2.9-3</literal>, your binary-only NMU should carry a version of

-<literal>2.9-3+b1</literal>.  If the latest version was <literal>3.4+b1
-</literal> (i.e, a native package with a previous recompilation NMU), your
-binary-only NMU should have a version number of <literal>3.4+b2</literal>.
-<footnote><para> In the past, such NMUs used the third-level number on the
+<literal>2.9-3+b1</literal>.  If the latest version was <literal>3.4+b1</literal>
+(i.e, a native package with a previous recompilation NMU), your
+binary-only NMU should have a version number of <literal>3.4+b2</literal>.<footnote><para>
+In the past, such NMUs used the third-level number on the

 Debian part of the revision to denote their recompilation-only status;
 however, this syntax was ambiguous with native packages and did not allow
 proper ordering of recompile-only NMUs, source NMUs, and security NMUs on
 Debian part of the revision to denote their recompilation-only status;
 however, this syntax was ambiguous with native packages and did not allow
 proper ordering of recompile-only NMUs, source NMUs, and security NMUs on


@@ -1690,7 +1689,7 @@ to only build the architecture-dependent parts of the package.
 <title>When to do a source NMU if you are a porter</title>
 <para>
 Porters doing a source NMU generally follow the guidelines found in <xref
 <title>When to do a source NMU if you are a porter</title>
 <para>
 Porters doing a source NMU generally follow the guidelines found in <xref

-linkend="nmu"/> , just like non-porters.  However, it is expected that the wait
+linkend="nmu"/>, just like non-porters.  However, it is expected that the wait

 cycle for a porter's source NMU is smaller than for a non-porter, since porters
 have to cope with a large quantity of packages.  Again, the situation varies
 depending on the distribution they are uploading to.  It also varies whether
 cycle for a porter's source NMU is smaller than for a non-porter, since porters
 have to cope with a large quantity of packages.  Again, the situation varies
 depending on the distribution they are uploading to.  It also varies whether


@@ -1706,7 +1705,7 @@ on the <literal>unstable</literal> distribution.  This period can be shortened
 if the problem is critical and imposes hardship on the porting effort, at the
 discretion of the porter group.  (Remember, none of this is Policy, just
 mutually agreed upon guidelines.) For uploads to <literal>stable</literal> or
 if the problem is critical and imposes hardship on the porting effort, at the
 discretion of the porter group.  (Remember, none of this is Policy, just
 mutually agreed upon guidelines.) For uploads to <literal>stable</literal> or

-<literal>testing </literal>, please coordinate with the appropriate release
+<literal>testing</literal>, please coordinate with the appropriate release

 team first.
 </para>
 <para>
 team first.
 </para>
 <para>


@@ -1769,9 +1768,9 @@ linkend="tools-porting"/>.
 <para>
 The <systemitem role="package">wanna-build</systemitem> system is used as a
 distributed, client-server build distribution system.  It is usually used in
 <para>
 The <systemitem role="package">wanna-build</systemitem> system is used as a
 distributed, client-server build distribution system.  It is usually used in

-conjunction with build daemons running the <systemitem role="package">buildd
-</systemitem> program. <literal>Build daemons</literal> are ``slave'' hosts
-which contact the central <systemitem role="package"> wanna-build</systemitem>
+conjunction with build daemons running the <systemitem role="package">buildd</systemitem>
+program. <literal>Build daemons</literal> are ``slave'' hosts
+which contact the central <systemitem role="package">wanna-build</systemitem>

 system to receive a list of packages that need to be built.
 </para>
 <para>
 system to receive a list of packages that need to be built.
 </para>
 <para>


@@ -1784,8 +1783,8 @@ version is not the same as the one used on build daemons, but it is close
 enough to reproduce problems.
 </para>
 <para>
 enough to reproduce problems.
 </para>
 <para>

-Most of the data produced by <systemitem role="package">wanna-build
-</systemitem> which is generally useful to porters is available on the
+Most of the data produced by <systemitem role="package">wanna-build</systemitem>
+which is generally useful to porters is available on the

 web at <ulink url="&url-buildd;"></ulink>.  This data includes nightly
 updated statistics, queueing information and logs for build attempts.
 </para>
 web at <ulink url="&url-buildd;"></ulink>.  This data includes nightly
 updated statistics, queueing information and logs for build attempts.
 </para>


@@ -1845,7 +1844,7 @@ fail also, and indicate this to a human reader without actually trying.
 <listitem>
 <para>
 In order to prevent autobuilders from needlessly trying to build your package,
 <listitem>
 <para>
 In order to prevent autobuilders from needlessly trying to build your package,

-it must be included in <filename>packages-arch-specific</filename>, a list used
+it must be included in <filename>Packages-arch-specific</filename>, a list used

 by the <command>wanna-build</command> script.  The current version is available
 as <ulink url="&url-buildd-p-a-s;"/>;
 please see the top of the file for whom to contact for changes.
 by the <command>wanna-build</command> script.  The current version is available
 as <ulink url="&url-buildd-p-a-s;"/>;
 please see the top of the file for whom to contact for changes.


@@ -1854,12 +1853,12 @@ please see the top of the file for whom to contact for changes.
 </itemizedlist>
 <para>
 Please note that it is insufficient to only add your package to
 </itemizedlist>
 <para>
 Please note that it is insufficient to only add your package to

-Packages-arch-specific without making it fail to build on unsupported
+<filename>Packages-arch-specific</filename> without making it fail to build on unsupported

 architectures: A porter or any other person trying to build your package might
 accidently upload it without noticing it doesn't work.  If in the past some
 binary packages were uploaded on unsupported architectures, request their
 removal by filing a bug against <systemitem
 architectures: A porter or any other person trying to build your package might
 accidently upload it without noticing it doesn't work.  If in the past some
 binary packages were uploaded on unsupported architectures, request their
 removal by filing a bug against <systemitem

-role="package">ftp.debian.org</systemitem>
+role="package">ftp.debian.org</systemitem>.

 </para>
 </section>
 
 </para>
 </section>
 


@@ -1928,7 +1927,7 @@ is given an opportunity to upload a fix on their own.
 When doing an NMU, you must first make sure that your intention to NMU is
 clear.  Then, you must send a patch with the differences between the
 current package and your proposed NMU to the BTS. The
 When doing an NMU, you must first make sure that your intention to NMU is
 clear.  Then, you must send a patch with the differences between the
 current package and your proposed NMU to the BTS. The

-<literal>nmudiff</literal> script in the <literal>devscripts</literal> package
+<command>nmudiff</command> script in the <systemitem role="package">devscripts</systemitem> package

 might be helpful.
 </para>
 <para>
 might be helpful.
 </para>
 <para>


@@ -1937,7 +1936,7 @@ practices that the maintainer might be using. Taking them into account reduces
 the burden of getting your changes integrated back in the normal package
 workflow and thus increases the possibilities that that will happen. A good
 place where to look for for possible package-specific practices is
 the burden of getting your changes integrated back in the normal package
 workflow and thus increases the possibilities that that will happen. A good
 place where to look for for possible package-specific practices is

-<ulink url="&url-debian-policy;ch-source.html#s-readmesource"><literal>debian/README.source</literal></ulink>.
+<ulink url="&url-debian-policy;ch-source.html#s-readmesource"><filename>debian/README.source</filename></ulink>.

 </para>
 <para>
 Unless you have an excellent reason not to do so, you must then give some time
 </para>
 <para>
 Unless you have an excellent reason not to do so, you must then give some time


@@ -1995,10 +1994,10 @@ defend the wisdom of any NMU you perform on its own merits.
 </section>
 
 <section id="nmu-changelog">
 </section>
 
 <section id="nmu-changelog">

-<title>NMUs and debian/changelog</title>
+<title>NMUs and <filename>debian/changelog</filename></title>

 <para>
 Just like any other (source) upload, NMUs must add an entry to
 <para>
 Just like any other (source) upload, NMUs must add an entry to

-<literal>debian/changelog</literal>, telling what has changed with this
+<filename>debian/changelog</filename>, telling what has changed with this

 upload.  The first line of this entry must explicitely mention that this upload is an NMU, e.g.:
 </para>
 <screen>
 upload.  The first line of this entry must explicitely mention that this upload is an NMU, e.g.:
 </para>
 <screen>


@@ -2009,7 +2008,7 @@ upload.  The first line of this entry must explicitely mention that this upload
 The way to version NMUs differs for native and non-native packages.
 </para>
 <para>
 The way to version NMUs differs for native and non-native packages.
 </para>
 <para>

-If the package is a native package (without a debian revision in the version number),
+If the package is a native package (without a Debian revision in the version number),

 the version must be the version of the last maintainer upload, plus
 <literal>+nmu<replaceable>X</replaceable></literal>, where
 <replaceable>X</replaceable> is a counter starting at <literal>1</literal>.
 the version must be the version of the last maintainer upload, plus
 <literal>+nmu<replaceable>X</replaceable></literal>, where
 <replaceable>X</replaceable> is a counter starting at <literal>1</literal>.


@@ -2020,11 +2019,11 @@ version <literal>1.5+nmu1</literal>.
 </para>
 <para>
 If the package is a not a native package, you should add a minor version number
 </para>
 <para>
 If the package is a not a native package, you should add a minor version number

-to the debian revision part of the version number (the portion after the last
-hyphen). This extra number must start at 1.  For example,
+to the Debian revision part of the version number (the portion after the last
+hyphen). This extra number must start at <literal>1</literal>.  For example,

 if the current version is <literal>1.5-2</literal>, then an NMU would get
 version <literal>1.5-2.1</literal>. If a new upstream version
 if the current version is <literal>1.5-2</literal>, then an NMU would get
 version <literal>1.5-2.1</literal>. If a new upstream version

-is packaged in the NMU, the debian revision is set to <literal>0</literal>, for
+is packaged in the NMU, the Debian revision is set to <literal>0</literal>, for

 example <literal>1.6-0.1</literal>.
 </para>
 <para>
 example <literal>1.6-0.1</literal>.
 </para>
 <para>


@@ -2054,14 +2053,14 @@ should be used, where <replaceable>X</replaceable> and
 When the release number is not yet known (often the case for
 <literal>testing</literal>, at the beginning of release cycles), the lowest
 release number higher than the last stable release number must be used.  For
 When the release number is not yet known (often the case for
 <literal>testing</literal>, at the beginning of release cycles), the lowest
 release number higher than the last stable release number must be used.  For

-example, while Etch (Debian 4.0) is stable, a security NMU to stable for a
+example, while Lenny (Debian 5.0) is stable, a security NMU to stable for a

 package at version <literal>1.5-3</literal> would have version
 package at version <literal>1.5-3</literal> would have version

-<literal>1.5-3+deb40u1</literal>, whereas a security NMU to Lenny would get
-version <literal>1.5-3+deb50u1</literal>. After the release of Lenny, security
+<literal>1.5-3+deb50u1</literal>, whereas a security NMU to Squeeze would get
+version <literal>1.5-3+deb60u1</literal>. After the release of Squeeze, security

 uploads to the <literal>testing</literal> distribution will be versioned
 uploads to the <literal>testing</literal> distribution will be versioned

-<literal>+deb51uZ</literal>, until it is known whether that release will be
-Debian 5.1 or Debian 6.0 (if that becomes the case, uploads will be versioned
-as <literal>+deb60uZ</literal>.
+<literal>+deb61uZ</literal>, until it is known whether that release will be
+Debian 6.1 or Debian 7.0 (if that becomes the case, uploads will be versioned
+as <literal>+deb70uZ</literal>).

 </para>
 </section>
 
 </para>
 </section>
 


@@ -2138,7 +2137,7 @@ package is used.
 
 <para>
 BinNMUs are usually triggered on the buildds by wanna-build.
 
 <para>
 BinNMUs are usually triggered on the buildds by wanna-build.

-An entry is added to debian/changelog,
+An entry is added to <filename>debian/changelog</filename>,

 explaining why the upload was needed and increasing the version number as
 described in <xref linkend="binary-only-nmu"/>.
 This entry should not be included in the next upload.
 explaining why the upload was needed and increasing the version number as
 described in <xref linkend="binary-only-nmu"/>.
 This entry should not be included in the next upload.


@@ -2147,7 +2146,7 @@ This entry should not be included in the next upload.
 <para>
 Buildds upload packages for their architecture to the archive as binary-only
 uploads.  Strictly speaking, these are binNMUs.  However, they are not normally
 <para>
 Buildds upload packages for their architecture to the archive as binary-only
 uploads.  Strictly speaking, these are binNMUs.  However, they are not normally

-called NMU, and they don't add an entry to debian/changelog.
+called NMU, and they don't add an entry to <filename>debian/changelog</filename>.

 </para>
 
 </section>
 </para>
 
 </section>


@@ -2165,8 +2164,8 @@ uploads are uploads of orphaned packages.
 <para>
 QA uploads are very much like normal maintainer uploads: they may fix anything,
 even minor issues; the version numbering is normal, and there is no need to use
 <para>
 QA uploads are very much like normal maintainer uploads: they may fix anything,
 even minor issues; the version numbering is normal, and there is no need to use

-a delayed upload.  The difference is that you are not listed as the Maintainer
-or Uploader for the package.  Also, the changelog entry of a QA upload has a
+a delayed upload.  The difference is that you are not listed as the <literal>Maintainer</literal>
+or <literal>Uploader</literal> for the package.  Also, the changelog entry of a QA upload has a

 special first line:
 </para>
 
 special first line:
 </para>
 


@@ -2199,14 +2198,18 @@ the new version (see <xref linkend="adopting"/>).
 
 <para>
 Sometimes you are fixing and/or updating a package because you are member of a
 
 <para>
 Sometimes you are fixing and/or updating a package because you are member of a

-packaging team (which uses a mailing list as Maintainer or Uploader, see <xref
-linkend="collaborative-maint"/>) but you don't want to add yourself to Uploaders
+packaging team (which uses a mailing list as <literal>Maintainer</literal> or <literal>Uploader</literal>, see <xref
+linkend="collaborative-maint"/>) but you don't want to add yourself to <literal>Uploaders</literal>

 because you do not plan to contribute regularly to this specific package. If it
 conforms with your team's policy, you can perform a normal upload without
 because you do not plan to contribute regularly to this specific package. If it
 conforms with your team's policy, you can perform a normal upload without

-being listed directly as Maintainer or Uploader. In that case, you should
-start your changelog entry with the following line: <code> * Team upload.</code>.
+being listed directly as <literal>Maintainer</literal> or <literal>Uploader</literal>. In that case, you should
+start your changelog entry with the following line:

 </para>
 
 </para>
 

+<screen>
+ * Team upload.
+</screen>
+

 </section>
 
 </section>
 </section>
 
 </section>


@@ -2218,7 +2221,7 @@ Collaborative maintenance is a term describing the sharing of Debian package
 maintenance duties by several people.  This collaboration is almost always a
 good idea, since it generally results in higher quality and faster bug fix
 turnaround times.  It is strongly recommended that packages with a priority of
 maintenance duties by several people.  This collaboration is almost always a
 good idea, since it generally results in higher quality and faster bug fix
 turnaround times.  It is strongly recommended that packages with a priority of

-<literal>Standard</literal> or which are part of the base set have
+<literal>standard</literal> or which are part of the base set have

 co-maintainers.
 </para>
 <para>
 co-maintainers.
 </para>
 <para>


@@ -2238,7 +2241,7 @@ easy:
 <para>
 Setup the co-maintainer with access to the sources you build the package from.
 Generally this implies you are using a network-capable version control system,
 <para>
 Setup the co-maintainer with access to the sources you build the package from.
 Generally this implies you are using a network-capable version control system,

-such as <command>CVS</command> or <command>Subversion</command>.  Alioth (see
+such as <literal>CVS</literal> or <literal>Subversion</literal>.  Alioth (see

 <xref linkend="alioth"/>) provides such tools, amongst others.
 </para>
 </listitem>
 <xref linkend="alioth"/>) provides such tools, amongst others.
 </para>
 </listitem>


@@ -2262,21 +2265,21 @@ should subscribe themselves to the appropriate source package.
 <para>
 Another form of collaborative maintenance is team maintenance, which is
 recommended if you maintain several packages with the same group of developers.
 <para>
 Another form of collaborative maintenance is team maintenance, which is
 recommended if you maintain several packages with the same group of developers.

-In that case, the Maintainer and Uploaders field of each package must be
+In that case, the <literal>Maintainer</literal> and <literal>Uploaders</literal> field of each package must be

 managed with care.  It is recommended to choose between one of the two
 following schemes:
 </para>
 <orderedlist numeration="arabic">
 <listitem>
 <para>
 managed with care.  It is recommended to choose between one of the two
 following schemes:
 </para>
 <orderedlist numeration="arabic">
 <listitem>
 <para>

-Put the team member mainly responsible for the package in the Maintainer field.
-In the Uploaders, put the mailing list address, and the team members who care
+Put the team member mainly responsible for the package in the <literal>Maintainer</literal> field.
+In the <literal>Uploaders</literal>, put the mailing list address, and the team members who care

 for the package.
 </para>
 </listitem>
 <listitem>
 <para>
 for the package.
 </para>
 </listitem>
 <listitem>
 <para>

-Put the mailing list address in the Maintainer field.  In the Uploaders field,
+Put the mailing list address in the <literal>Maintainer</literal> field.  In the <literal>Uploaders</literal> field,

 put the team members who care for the package.  In this case, you must make
 sure the mailing list accept bug reports without any human interaction (like
 moderation for non-subscribers).
 put the team members who care for the package.  In this case, you must make
 sure the mailing list accept bug reports without any human interaction (like
 moderation for non-subscribers).


@@ -2286,14 +2289,14 @@ moderation for non-subscribers).
 
 <para>
 In any case, it is a bad idea to automatically put all team members in the
 
 <para>
 In any case, it is a bad idea to automatically put all team members in the

-Uploaders field. It clutters the Developer's Package Overview listing (see
+<literal>Uploaders</literal> field. It clutters the Developer's Package Overview listing (see

 <xref linkend="ddpo"/>) with packages one doesn't really care for, and creates
 a false sense of good maintenance. For the same reason, team members do
 <xref linkend="ddpo"/>) with packages one doesn't really care for, and creates
 a false sense of good maintenance. For the same reason, team members do

-not need to add themselves to the Uploaders field just because they are
+not need to add themselves to the <literal>Uploaders</literal> field just because they are

 uploading the package once, they can do a “Team upload” (see <xref
 linkend="nmu-team-upload"/>). Conversely, it it a bad idea to keep a
 uploading the package once, they can do a “Team upload” (see <xref
 linkend="nmu-team-upload"/>). Conversely, it it a bad idea to keep a

-package with only the mailing list address as a Maintainer and no
-Uploaders.
+package with only the mailing list address as a <literal>Maintainer</literal> and no
+<literal>Uploaders</literal>.

 </para>
 </section>
 
 </para>
 </section>
 


@@ -2309,8 +2312,8 @@ after they have undergone some degree of <literal>testing</literal> in
 <para>
 They must be in sync on all architectures and mustn't have dependencies that
 make them uninstallable; they also have to have generally no known
 <para>
 They must be in sync on all architectures and mustn't have dependencies that
 make them uninstallable; they also have to have generally no known

-release-critical bugs at the time they're installed into <literal>testing
-</literal>.  This way, <literal>testing</literal> should always be close to
+release-critical bugs at the time they're installed into <literal>testing</literal>.
+This way, <literal>testing</literal> should always be close to

 being a release candidate.  Please see below for details.
 </para>
 </section>
 being a release candidate.  Please see below for details.
 </para>
 </section>


@@ -2350,7 +2353,7 @@ available in <literal>unstable</literal>, but not affecting the version in
 <listitem>
 <para>
 It must be available on all architectures on which it has previously been built
 <listitem>
 <para>
 It must be available on all architectures on which it has previously been built

-in <literal>unstable</literal>.  <xref linkend="dak-ls"/> may be of interest
+in <literal>unstable</literal>. <link linkend="dak-ls">dak ls</link> may be of interest

 to check that information;
 </para>
 </listitem>
 to check that information;
 </para>
 </listitem>


@@ -2365,7 +2368,7 @@ It must not break any dependency of a package which is already available in
 The packages on which it depends must either be available in
 <literal>testing</literal> or they must be accepted into
 <literal>testing</literal> at the same time (and they will be if they fulfill
 The packages on which it depends must either be available in
 <literal>testing</literal> or they must be accepted into
 <literal>testing</literal> at the same time (and they will be if they fulfill

-all the necessary criteria);
+all the necessary criteria).

 </para>
 </listitem>
 </itemizedlist>
 </para>
 </listitem>
 </itemizedlist>


@@ -2398,7 +2401,7 @@ url="http://release.debian.org/migration/"></ulink> — but be warned, this page
 shows build dependencies which are not considered by britney.
 </para>
 <section id="outdated">
 shows build dependencies which are not considered by britney.
 </para>
 <section id="outdated">

-<title>out-of-date</title>
+<title>Out-of-date</title>

 <para>
 <!-- FIXME: better rename this file than document rampant professionalism? -->
 For the <literal>testing</literal> migration script, outdated means: There are
 <para>
 <!-- FIXME: better rename this file than document rampant professionalism? -->
 For the <literal>testing</literal> migration script, outdated means: There are


@@ -2435,10 +2438,10 @@ Consider this example:
 </tgroup>
 </informaltable>
 <para>
 </tgroup>
 </informaltable>
 <para>

-The package is out of date on alpha in <literal>unstable</literal>, and will
+The package is out of date on <literal>alpha</literal> in <literal>unstable</literal>, and will

 not go to <literal>testing</literal>. Removing the package would not help at all, the
 package is still out of date on <literal>alpha</literal>, and will not
 not go to <literal>testing</literal>. Removing the package would not help at all, the
 package is still out of date on <literal>alpha</literal>, and will not

-propagate to testing.
+propagate to <literal>testing</literal>.

 </para>
 <para>
 However, if ftp-master removes a package in <literal>unstable</literal> (here
 </para>
 <para>
 However, if ftp-master removes a package in <literal>unstable</literal> (here


@@ -2492,8 +2495,8 @@ with the new version of <literal>b</literal>; then <literal>a</literal> may
 be removed to allow <literal>b</literal> in.
 </para>
 <para>
 be removed to allow <literal>b</literal> in.
 </para>
 <para>

-Of course, there is another reason to remove a package from <literal>testing
-</literal>: It's just too buggy (and having a single RC-bug is enough to be
+Of course, there is another reason to remove a package from <literal>testing</literal>:
+It's just too buggy (and having a single RC-bug is enough to be

 in this state).
 </para>
 <para>
 in this state).
 </para>
 <para>


@@ -2504,7 +2507,7 @@ will automatically be removed.
 </section>
 
 <section id="circular">
 </section>
 
 <section id="circular">

-<title>circular dependencies</title>
+<title>Circular dependencies</title>

 <para>
 A situation which is not handled very well by britney is if package
 <literal>a</literal> depends on the new version of package
 <para>
 A situation which is not handled very well by britney is if package
 <literal>a</literal> depends on the new version of package


@@ -2548,28 +2551,28 @@ happens to one of your packages.
 </section>
 
 <section id="s5.13.2.4">
 </section>
 
 <section id="s5.13.2.4">

-<title>influence of package in testing</title>
+<title>Influence of package in testing</title>

 <para>
 <para>

-Generally, there is nothing that the status of a package in <literal>testing
-</literal> means for transition of the next version from <literal>unstable
-</literal> to <literal>testing</literal>, with two exceptions:
+Generally, there is nothing that the status of a package in <literal>testing</literal>
+means for transition of the next version from <literal>unstable</literal>
+to <literal>testing</literal>, with two exceptions:

 If the RC-bugginess of the package goes down, it may go in even if it is still
 If the RC-bugginess of the package goes down, it may go in even if it is still

-RC-buggy.  The second exception is if the version of the package in <literal>
-testing</literal> is out of sync on the different arches: Then any arch might
+RC-buggy.  The second exception is if the version of the package in
+<literal>testing</literal> is out of sync on the different arches: Then any arch might

 just upgrade to the version of the source package; however, this can happen
 only if the package was previously forced through, the arch is in fuckedarches,
 just upgrade to the version of the source package; however, this can happen
 only if the package was previously forced through, the arch is in fuckedarches,

-or there was no binary package of that arch present in <literal>unstable
-</literal> at all during the <literal>testing</literal> migration.
+or there was no binary package of that arch present in <literal>unstable</literal>
+at all during the <literal>testing</literal> migration.

 </para>
 <para>
 </para>
 <para>

-In summary this means: The only influence that a package being in <literal>
-testing</literal> has on a new version of the same package is that the new
+In summary this means: The only influence that a package being in
+<literal>testing</literal> has on a new version of the same package is that the new

 version might go in easier.
 </para>
 </section>
 
 <section id="details">
 version might go in easier.
 </para>
 </section>
 
 <section id="details">

-<title>details</title>
+<title>Details</title>

 <para>
 If you are interested in details, this is how britney works:
 </para>
 <para>
 If you are interested in details, this is how britney works:
 </para>


@@ -2583,8 +2586,8 @@ part of britney.) (There is a similar thing for binary-only updates, but this
 is not described here.  If you're interested in that, please peruse the code.)
 </para>
 <para>
 is not described here.  If you're interested in that, please peruse the code.)
 </para>
 <para>

-Now, the more complex part happens: Britney tries to update <literal>testing
-</literal> with the valid candidates. For that, britney tries to add each
+Now, the more complex part happens: Britney tries to update <literal>testing</literal>
+with the valid candidates. For that, britney tries to add each

 valid candidate to the testing distribution. If the number of uninstallable
 packages in <literal>testing</literal> doesn't increase, the package is
 accepted. From that point on, the accepted package is considered to be part
 valid candidate to the testing distribution. If the number of uninstallable
 packages in <literal>testing</literal> doesn't increase, the package is
 accepted. From that point on, the accepted package is considered to be part


@@ -2597,7 +2600,7 @@ If you want to see more details, you can look it up on
 <filename>merkel:/org/&ftp-debian-org;/testing/update_out/</filename> (or
 in <filename>merkel:~aba/testing/update_out</filename> to see a setup with
 a smaller packages file).  Via web, it's at <ulink
 <filename>merkel:/org/&ftp-debian-org;/testing/update_out/</filename> (or
 in <filename>merkel:~aba/testing/update_out</filename> to see a setup with
 a smaller packages file).  Via web, it's at <ulink

-url="http://&ftp-master-host;/testing/update_out_code/"></ulink>
+url="http://&ftp-master-host;/testing/update_out_code/"></ulink>.

 </para>
 <para>
 The hints are available via <ulink
 </para>
 <para>
 The hints are available via <ulink


@@ -2612,9 +2615,9 @@ url="http://&ftp-master-host;/testing/hints/"></ulink>.
 <para>
 The <literal>testing</literal> distribution is fed with packages from
 <literal>unstable</literal> according to the rules explained above.  However,
 <para>
 The <literal>testing</literal> distribution is fed with packages from
 <literal>unstable</literal> according to the rules explained above.  However,

-in some cases, it is necessary to upload packages built only for <literal>
-testing</literal>.  For that, you may want to upload to <literal>
-testing-proposed-updates</literal>.
+in some cases, it is necessary to upload packages built only for
+<literal>testing</literal>.  For that, you may want to upload to
+<literal>testing-proposed-updates</literal>.

 </para>
 <para>
 Keep in mind that packages uploaded there are not automatically processed, they
 </para>
 <para>
 Keep in mind that packages uploaded there are not automatically processed, they


@@ -2626,8 +2629,8 @@ give on &email-debian-devel-announce;.
 <para>
 You should not upload to <literal>testing-proposed-updates</literal> when you
 can update your packages through <literal>unstable</literal>.  If you can't
 <para>
 You should not upload to <literal>testing-proposed-updates</literal> when you
 can update your packages through <literal>unstable</literal>.  If you can't

-(for example because you have a newer development version in <literal>unstable
-</literal>), you may use this facility, but it is recommended that you ask for
+(for example because you have a newer development version in <literal>unstable</literal>),
+you may use this facility, but it is recommended that you ask for

 authorization from the release manager first.  Even if a package is frozen,
 updates through <literal>unstable</literal> are possible, if the upload via
 <literal>unstable</literal> does not pull in any new dependencies.
 authorization from the release manager first.  Even if a package is frozen,
 updates through <literal>unstable</literal> are possible, if the upload via
 <literal>unstable</literal> does not pull in any new dependencies.


@@ -2635,7 +2638,7 @@ updates through <literal>unstable</literal> are possible, if the upload via
 <para>
 Version numbers are usually selected by adding the codename of the
 <literal>testing</literal> distribution and a running number, like
 <para>
 Version numbers are usually selected by adding the codename of the
 <literal>testing</literal> distribution and a running number, like

-<literal>1.2sarge1</literal> for the first upload through
+<literal>1.2squeeze1</literal> for the first upload through

 <literal>testing-proposed-updates</literal> of package version
 <literal>1.2</literal>.
 </para>
 <literal>testing-proposed-updates</literal> of package version
 <literal>1.2</literal>.
 </para>


@@ -2646,8 +2649,8 @@ Please make sure you didn't miss any of these items in your upload:
 <listitem>
 <para>
 Make sure that your package really needs to go through
 <listitem>
 <para>
 Make sure that your package really needs to go through

-<literal>testing-proposed-updates</literal>, and can't go through <literal>
-unstable</literal>;
+<literal>testing-proposed-updates</literal>, and can't go through
+<literal>unstable</literal>;

 </para>
 </listitem>
 <listitem>
 </para>
 </listitem>
 <listitem>


@@ -2701,13 +2704,13 @@ currently, these are <literal>critical</literal>, <literal>grave</literal> and
 Such bugs are presumed to have an impact on the chances that the package will
 be released with the <literal>stable</literal> release of Debian: in general,
 if a package has open release-critical bugs filed on it, it won't get into
 Such bugs are presumed to have an impact on the chances that the package will
 be released with the <literal>stable</literal> release of Debian: in general,
 if a package has open release-critical bugs filed on it, it won't get into

-<literal>testing</literal>, and consequently won't be released in <literal>
-stable</literal>.
+<literal>testing</literal>, and consequently won't be released in
+<literal>stable</literal>.

 </para>
 <para>
 The <literal>unstable</literal> bug count are all release-critical bugs which
 </para>
 <para>
 The <literal>unstable</literal> bug count are all release-critical bugs which

-are marked to apply to <replaceable>package</replaceable>/<replaceable>version
-</replaceable> combinations that are available in unstable for a release
+are marked to apply to <replaceable>package</replaceable>/<replaceable>version</replaceable>
+combinations that are available in unstable for a release

 architecture. The <literal>testing</literal> bug count is defined analogously.
 </para>
 </section>
 architecture. The <literal>testing</literal> bug count is defined analogously.
 </para>
 </section>


@@ -2719,9 +2722,9 @@ break other packages?</title>
 The structure of the distribution archives is such that they can only contain
 one version of a package; a package is defined by its name.  So when the source
 package <literal>acmefoo</literal> is installed into <literal>testing</literal>,
 The structure of the distribution archives is such that they can only contain
 one version of a package; a package is defined by its name.  So when the source
 package <literal>acmefoo</literal> is installed into <literal>testing</literal>,

-along with its binary packages <literal>acme-foo-bin</literal>, <literal>
-acme-bar-bin</literal>, <literal>libacme-foo1</literal> and <literal>
-libacme-foo-dev</literal>, the old version is removed.
+along with its binary packages <literal>acme-foo-bin</literal>,
+<literal>acme-bar-bin</literal>, <literal>libacme-foo1</literal> and
+<literal>libacme-foo-dev</literal>, the old version is removed.

 </para>
 <para>
 However, the old version may have provided a binary package with an old soname
 </para>
 <para>
 However, the old version may have provided a binary package with an old soname

diff --git a/resources.dbk b/resources.dbk
index c83e8a92e45e17a13d620200e0280de79048eee0..c4ab2eb2184254fc55dad257b5c657b790fcca25 100644 (file)
--- a/resources.dbk
+++ b/resources.dbk
@@ -1487,7 +1487,7 @@ item.
 </para>
 <para>
 Here are a few examples of valid mails used to generate news items in the PTS.
 </para>
 <para>
 Here are a few examples of valid mails used to generate news items in the PTS.

-The first one adds a link to the cvsweb interface of debian-cd in the Static
+The first one adds a link to the viewsvn interface of debian-cd in the Static

 information section:
 </para>
 <screen>
 information section:
 </para>
 <screen>