<!ENTITY % dynamicdata SYSTEM "dynamic.ent" > %dynamicdata;
<!-- CVS revision of this document -->
- <!ENTITY cvs-rev "$Revision: 1.299 $">
+ <!ENTITY cvs-rev "$Revision: 1.302 $">
<!-- if you are translating this document, please notate the CVS
revision of the original developer's reference in cvs-en-rev -->
Delayed uploads are done for the moment via the delayed queue at
gluck. The upload-directory is
<ftpsite>gluck:~tfheen/DELAYED/[012345678]-day</ftpsite>.
-0-day is uploaded approximately one hour before dinstall runs.
+0-day is uploaded multiple times per day to ftp-master.
<p>
With a fairly recent dput, this section
<example>
<sect1>Security uploads
<p>
-Do NOT upload a package to the security upload queue (oldstable-security,
+Do <strong>NOT</strong> upload a package to the security upload queue
+(oldstable-security,
stable-security, etc.) without prior authorization from the security
team. If the package does not exactly meet the team's requirements, it
will cause many problems and delays in dealing with the unwanted upload.
been accepted into the Debian archive. Therefore, once you get
notification that your updated package has been installed into the
archive, you can and should close the bug in the BTS.
+Also, the bug should be closed with the correct version.
<p>
However, it's possible to avoid having to manually close bugs after the
upload — just list the fixed bugs in your <file>debian/changelog</file>
We prefer the <tt>closes: #<var>XXX</var></tt> syntax, as it is the
most concise entry and the easiest to integrate with the text of the
<file>changelog</file>.
+Unless specified different by the <var>-v</var>-switch to
+<prgn>dpkg-buildpackage</prgn>, only the bugs closed in the
+most recent changelog entry are closed (basically, exactly
+the bugs mentioned in the changelog-part
+in the <file>.changes</file> file are closed).
<p>
Historically, uploads identified as
<qref id="nmu">Non-maintainer upload (NMU)</qref>
the bug tracking system's control address, &email-bts-control;. To
close any remaining bugs that were fixed by your upload, email the
<file>.changes</file> file to <email>XXX-done@&bugs-host;</email>,
-where <var>XXX</var> is your bug number, and write "Version: XXX"
-in the first line of the body of the email to mark the first version
-where this bug has been closed.
+where <var>XXX</var> is your bug number, and
+put "Version: XXX" and an empty line as the first two lines
+of the body of the email
+to mark the first version where this bug has been closed.
<p>
Bear in mind that it is not obligatory to close bugs using the
changelog as described above. If you simply want to close bugs that
package. When invoked as <tt>apt-cache showpkg
<var>package</var></tt>, the program will show details for
<var>package</var>, including reverse depends.
+Other useful programs include
+<tt>apt-cache rdepends</tt>,
+<prgn>apt-rdepends</prgn> and
+<prgn>grep-dctrl>.
Removal of orphaned packages is discussed on &email-debian-qa;.
<p>
Once the package has been removed, the package's bugs should be handled.
<sect3>boolean:
<p>
-A true/false choice. Remember: true/false, NOT YES/NO...
+A true/false choice. Remember: true/false, <strong>not yes/no</strong>...
<sect3>select:
<p>
<sect3>String/password templates
<p>
<list>
-<item> The short description is a prompt and NOT a title. Avoid
+<item> The short description is a prompt and <strong>not</strong> a title. Avoid
question style prompts ("IP Address?") in favour of
"opened" prompts ("IP address:").
The use of colons is recommended.
question is rather long (remember that translations are often longer
than original versions)
-<item> The extended description should NOT include a question.
+<item> The extended description should <strong>not</strong> include a question.
<item> Again, please avoid referring to specific interface widgets. A common
mistake for such templates is "if you answer Yes"-type
<sect3>Select/Multiselect
<p>
<list>
-<item> The short description is a prompt and NOT a title. Do NOT use useless
+<item> The short description is a prompt and <strong>not</strong> a title.
+ Do <strong>not</strong> use useless
"Please choose..." constructions. Users are clever enough to figure
out they have to choose something...:)
<item> The extended description is what will be displayed as a more detailed
explanation of the note. Phrases, no terse writing style.
-<item> DO NOT ABUSE DEBCONF. Notes are the most common way to abuse
+<item> <strong>Do not abuse debconf.</strong>
+ 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.
Do NOT use empty default field. If you don't want to use default
values, do not use Default at all.
<p>
-If you use po-debconf (and you SHOULD, see 2.2), consider making this
+If you use po-debconf (and you <strong>should</strong>, see 2.2), consider making this
field translatable, if you think it may be translated.
<p>
If the default value may vary depending on language/country (for
It unpacks the tarball in an empty temporary directory by doing
<example>
-zcat path/to/<packagename>_<upstream-version>.orig.tar.gz | tar xf - +</example>
+zcat path/to/<packagename>_<upstream-version>.orig.tar.gz | tar xf -
+</example>
</item>
<item>
If, after this, the temporary directory contains nothing but one
<strong>should</strong> use
<tt><packagename>-<upstream-version>.orig</tt> as the name
of the top-level directory in its tarball. This makes it possible to
-distinguish pristine tarballs from repackaged ones. + </item>
+distinguish pristine tarballs from repackaged ones.
+ </item>
<item>
<strong>should</strong> be gzipped with maximal compression.
</item>
~ianmdlvl / developers-reference.git / blobdiff