<!ENTITY % commondata SYSTEM "common.ent" > %commondata;
<!-- CVS revision of this document -->
- <!ENTITY cvs-rev "$Revision: 1.241 $">
+ <!ENTITY cvs-rev "$Revision: 1.244 $">
<!-- if you are translating this document, please notate the CVS
revision of the original developer's reference in cvs-en-rev -->
Read the documentation that comes with your software; read the <url
id="&url-pgp-faq;" name="PGP FAQ">.
<p>
+You need to ensure not only that your key is secure against being stolen,
+but also that it is secure against being lost. Generate and make a copy
+(best also in paper form) of your revocation certificate; this is needed if
+your key is lost.
+ <p>
If you add signatures to your public key, or add user identities, you
can update the Debian key ring by sending your key to the key server at
<tt>&keyserver-host;</tt>. If you need to add a completely new key,
<item>
If the bug is real but it's caused by another package, just reassign
the bug to the right package. If you don't know which package it should
-be reassigned to, you may either ask for help on &email-debian-devel; or
-reassign it to <package>debian-policy</package> to let them decide which
-package is at fault.
+be reassigned to, you should ask for help on
+<qref id="irc-channels">IRC</qref> or on &email-debian-devel;.
<p>
Sometimes you also have to adjust the severity of the bug so that it
matches our definition of the severity. That's because people tend to
official package maintainer to make a release of a package. This is
called a non-maintainer upload, or NMU.
<p>
-This sections handles only source NMUs, i.e. NMUs which upload a new
+This section handles only source NMUs, i.e. NMUs which upload a new
version of the package. For binary-only NMUs by porters or QA members,
please see <ref id="binary-only-nmu">.
For buildd uploads (which are strictly speaking also NMUs), please see <ref
If one of your packages has been NMU'ed, you have to incorporate the
changes in your copy of the sources. This is easy, you just have
to apply the patch that has been sent to you. Once this is done, you
-have to close the bugs that have been tagged fixed by the NMU. You
-can either close them manually by sending the required mails to the
+have to close the bugs that have been tagged fixed by the NMU. The easiest
+way is to use the <tt>-v</tt> option of <prgn>dpkg-buildpackage</prgn>,
+as this allows you to include just all changes since your last maintainer
+upload. Alternativly, you
+can close them manually by sending the required mails to the
BTS or by adding the required <tt>closes: #nnnn</tt> in the changelog
entry of your next upload.
<p>
Version numbers are usually selected by adding the codename of the testing
distribution and a incrementing number, like 1.2sarge1 for the first upload
through testing-proposed-updates of the package version 1.2.
+ <p>
+Please make sure you didn't miss any of these items at your upload:
+<list>
+<item> Make sure that your package really needs to go through
+<em>testing-proposed-uploads</em>, and can't go through unstable;
+<item> Make sure that you included only the minimal amount of changes;
+<item> Make sure that you included an appropriate explaination in the
+changelog;
+<item> Make sure that you've written <em>testing</em> or
+<em>testing-proposed-updates</em> into your target distribution;
+<item> Make sure that you've build and tested your package in
+<em>testing</em>, not in <em>unstable</em>;
+<item> Make sure that your version number is higher than the version in
+<em>testing</em> and <em>testing-proposed-updates</em>, and lower than in
+<em>unstable</em>;
+<item> After uploading and successful build on all platforms, contact the
+release team at &email-debian-release; and ask them to approve your upload.
+</list>
<sect1 id="faq">
~ianmdlvl / developers-reference.git / blobdiff