chiark / gitweb /
translation status checking tool, based on documentation/doc-check
[developers-reference.git] / developers-reference.sgml
index 6624ddd7d034fa889860dcf9f4e41c1e066ae728..6ffa1bac9fcb450ea0d876a5b7e52cc1d1e00199 100644 (file)
@@ -6,7 +6,7 @@
   <!entity % commondata  SYSTEM "common.ent" > %commondata;
 
   <!-- CVS revision of this document -->
-  <!entity cvs-rev "$Revision: 1.141 $">
+  <!entity cvs-rev "$Revision: 1.144 $">
   <!-- if you are translating this document, please notate the CVS
        revision of the developers reference here -->
   <!--
 
       <copyright>
        <copyrightsummary>
-copyright &copy;1998&mdash;2002 Adam Di Carlo</copyrightsummary>
+copyright &copy; 1998&mdash;2002 Adam Di Carlo</copyrightsummary>
        <copyrightsummary>
-copyright &copy;2002 Raphaël Hertzog</copyrightsummary>
+copyright &copy; 2002 Raphaël Hertzog</copyrightsummary>
        <copyrightsummary>
-copyright &copy;1997, 1998 Christian Schwarz</copyrightsummary>
+copyright &copy; 1997, 1998 Christian Schwarz</copyrightsummary>
        <p>
 This manual is free software; you may redistribute it and/or modify it
 under the terms of the GNU General Public License as published by the
@@ -397,7 +397,7 @@ the following steps:
            <item>
 Orphan all your packages, as described in <ref id="orphaning">.
            <item>
-Send an email about how you are leaving the project to
+Send an email about why you are leaving the project to
 &email-debian-private;.
            <item>
 Notify the Debian key ring maintainers that you are leaving by
@@ -1179,7 +1179,7 @@ recompiled on most of the architectures.
 The Package Tracking System (PTS) is basically a tool to track by mail
 the activity of a source package. You just have to subscribe
 to a source package to start getting the mails related to it. 
-You get the same mails than the maintainer. Each mail
+You get the same mails as the maintainer. Each mail
 sent through the PTS is classified and associated to one of
 the keyword listed below. This will let you select the mails that
 you want to receive.
@@ -2902,15 +2902,6 @@ anything to do with an upload of yours, do it simply by emailing an
 explanation to <email>XXX-done@bugs.debian.org</email>.
 
 
-      <sect1 id="lintian-reports">Lintian reports
-       <p>
-You should periodically get the new <package>lintian</package> from
-`unstable' and check over all your packages.  Alternatively you can
-check for your maintainer email address at the <url id="&url-lintian;"
-name="online lintian report">.  That report, which is updated
-automatically, contains <prgn>lintian</prgn> reports against the
-latest version of the distribution (usually from 'unstable') using the
-latest <package>lintian</package>.
 
 
   <chapt id="best-pkging-practices">
@@ -2933,7 +2924,7 @@ even better.
        <p>
 To help you in your packaging effort, you can use helper scripts.
 The best scripts available are provided by <package>debhelper</package>.
-With <prgn>dh_make</prgn> (package <package>dh-make</package>), you can
+With <prgn>dh_make</prgn> (see <ref id="dh-make">), you can
 generate in a few seconds a package that is mostly ready. However that
 apparent simplicity is hiding many things done by the helper scripts.
 You have to know what is done by them, that's why you are strongly
@@ -3216,7 +3207,7 @@ list.
 Even though there is a dedicated group of people for Quality
 Assurance, QA duties are not reserved solely for them. You can
 participate in this effort by keeping your packages as bug-free as
-possible, and as lintian-clean (see <ref id="lintian-reports">) as
+possible, and as lintian-clean (see <ref id="lintian">) as
 possible. If you do not find that possible, then you should consider
 orphaning some of your packages (see <ref
 id="orphaning">). Alternatively, you may ask the help of other people
@@ -3409,9 +3400,20 @@ they are required for any Debian maintainer.
        <p>
 <package>Lintian</package> dissects Debian packages and reports bugs
 and policy violations. It contains automated checks for many aspects
-of Debian policy as well as some checks for common errors.  The use of
-<package>lintian</package> has already been discussed in <ref
-id="upload-checking"> and <ref id="lintian-reports">.
+of Debian policy as well as some checks for common errors.
+       <p>
+You should periodically get the newest <package>lintian</package> from
+`unstable' and check over all your packages. Notice that the <tt>-i</tt>
+option provides detailed explanations of what each error or warning means,
+what is its basis in Policy, and commonly how you can fix the problem.
+       <p>
+Refer to <ref id="upload-checking"> for more information on how and when
+to use Lintian.
+       <p>
+You can also see a summary of all problems reported by Lintian on your
+packages at <url id="&url-lintian;">. Those reports contain the latest
+<prgn>lintian</prgn> output on the whole development distribution
+("unstable").
 
 
       <sect id="debconf">
@@ -3469,6 +3471,21 @@ favor of <package>debhelper</package>.  However, it's not a bug to use
 <package>debmake</package>.
 
 
+      <sect id="dh-make">
+       <heading><package>dh-make</package>
+       <p>
+The <package/dh-make/ package contains <prgn/dh_make/, a program that
+creates a skeleton of files necessary to build a Debian package out of
+a source tree. As the name suggests, <prgn/dh_make/ is a rewrite of
+<package/debmake/ and its template files use dh_* programs from
+<package/debhelper/.
+       <p>
+While the rules files generated by <prgn/dh_make/ are in general a
+sufficient basis for a working package, they are still just the groundwork:
+the burden still lies on the maintainer to finely tune the generated files
+and make the package entirely functional and Policy-compliant.
+
+
       <sect id="yada">
        <heading><package>yada</package>
        <p>