<!ENTITY % dynamicdata SYSTEM "dynamic.ent" > %dynamicdata;
<!-- CVS revision of this document -->
- <!ENTITY cvs-rev "$Revision: 1.296 $">
+ <!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>.
- <p>
-If an upload is identified as <qref id="nmu">Non-maintainer upload (NMU)</qref>
-(and that is the case if the name of the person who commits this change
-is not exactly the same as any one of Maintainer or Uploader,
-except if the maintainer is the qa group),
-than the bug is only tagged <tt>fixed</tt> instead of being closed.
-If a maintainer upload is targetted to experimental,
-than the tag <tt>fixed-in-experimental</tt> is added to the bug;
-for NMUs, the tag <tt>fixed</tt> is used.
-(The special rule for experimental is expected to change
-as soon as version-tracking is added to the bug tracking system.)
+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>
+were tagged <tt>fixed</tt> instead of being closed,
+but that practice was ceased with the advent of version-tracking.
+The same applied to the tag <tt>fixed-in-experimental</tt>.
<p>
If you happen to mistype a bug number or forget a bug in the changelog
entries, don't hesitate to undo any damage the error caused. To reopen
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.
+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
removed automatically after the package has been removed from
<em>unstable</em> and no package in <em>testing</em> depends on it.
<p>
+If you are simply restructuring a source package so that it no longer
+produces one or more binary packages, there is no need to explicitly ask
+for the packages that are no longer created to be removed. Such packages
+will be removed when the new package structure has been uploaded into
+<em>unstable</em> and when no package in <em>testing</em> depends on it.
+ <p>
You also have to detail the reasons justifying that request. This is to
avoid unwanted removals and to keep a trace of why a package has been
removed. For example, you can provide the name of the package 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.
to the Bug Tracking System. Maintainers almost always appreciate
quality patches and bug reports.
- <sect1 id="nmu-katie">How dak detects NMUs
- <p>
-Whether an upload is treated as an NMU or as a maintainer upload by
-the archive scripts and the bugtracking system (see <ref
-id="nmu-patch">) is <em>not</em> decided by looking at the version
-number (see <ref id="nmu-version">). Instead, an upload is handled as
-an NMU if the maintainer address in the <tt>.changes</tt> file is not
-binary the same as the address in the <tt>Maintainer</tt> field, or
-any of the addresses the <tt>Uploaders</tt> field, of the <tt>dsc</tt>
-file, and also if the maintainer address is not special (i.e. it is
-not set to the QA Group address).
-
<sect1 id="nmu-terms">Terminology
<p>
There are two new terms used throughout this section: ``binary-only NMU''
<p>
Sometimes, a package is removed to allow another package in: This happens
only to allow <em>another</em> package to go in if it's ready in every other
-sense. Suppose e.g. that <em>a</em> conflicts with the new version of
+sense. Suppose e.g. that <em>a</em> cannot be installed with the new version of
<em>b</em>; then <em>a</em> may be removed to allow <em>b</em> in.
<p>
Of course, there is another reason to remove a package from testing: It's
just too buggy (and having a single RC-bug is enough to be in this state).
+ <p>
+Furthermore, if a package has been removed from unstable,
+and no package in testing depends on it any more,
+then it will automatically be removed.
+
<sect2 id="circular">
<heading>circular dependencies</heading>
<p>
It is an old tradition to acknowledge bugs fixed in non-maintainer
uploads in the first changelog entry of the proper maintainer upload.
-Please use the option <tt>-v</tt> to <prgn>dpkg-buildpackage</prgn>
-to close the relevant bug report.
+As we have version tracking now,
+it is enough to keep the NMUed changelog entries and
+just mention this fact in your own changelog entry.
</sect1>
<sect1 id="bpp-changelog-errors">
<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