<!ENTITY % dynamicdata SYSTEM "dynamic.ent" > %dynamicdata;
<!-- CVS revision of this document -->
- <!ENTITY cvs-rev "$Revision: 1.285 $">
+ <!ENTITY cvs-rev "$Revision: 1.291 $">
<!-- if you are translating this document, please notate the CVS
revision of the original developer's reference in cvs-en-rev -->
all its own user IDs; this prevents user ID tampering). All
modern OpenPGP software does that automatically, but if you
have an older key you may have to manually add those signatures.
-</footnode>
+</footnote>
<p>
If your public key isn't on public key servers such as &pgp-keyserv;,
please read the documentation available locally in &file-keyservs;.
<item>
Orphan all your packages, as described in <ref id="orphaning">.
<item>
-Send an email about why you are leaving the project to
+Send an gpg-signed email about why you are leaving the project to
&email-debian-private;.
<item>
Notify the Debian key ring maintainers that you are leaving by
These are the <manref name="sources.list" section="5"> lines for
<em>experimental</em>:
<example>
-deb http://ftp.<var>xy</var>.debian.org/debian/ ../project/experimental main
-deb-src http://ftp.<var>xy</var>.debian.org/debian/ ../project/experimental main
+deb http://ftp.<var>xy</var>.debian.org/debian/ experimental main
+deb-src http://ftp.<var>xy</var>.debian.org/debian/ experimental main
</example>
<p>
If there is a chance that the software could do grave damage to a system,
<item>
Translations of descriptions or debconf templates
submitted to the Debian Description Translation Project.
+
+ <tag><tt>derivatives</tt>
+ <item>
+Information about changes made to the package in derivative distributions
+(for example Ubuntu).
</taglist>
<sect1 id="pts-commands">The PTS email interface
<p>
You can control your subscription(s) to the PTS by sending
-various commands to <email>pts@qa.debian.org</email>.
+various commands to <email>pts@qa.debian.org</email>.
<taglist>
using the specified email address or the sender address if the second
argument is left out.
+<tag><tt>unsubscribeall [<email>]</tt>
+<item>
+ Removes all subscriptions of the specified email address or the sender
+ address if the second argument is left out.
+
<tag><tt>which [<email>]</tt>
<item>
Lists all subscriptions for the sender or the email address optionally
<item><tt>summary</tt>: automatic summary mails about the state of a package
<item><tt>cvs</tt>: notification of CVS commits
<item><tt>ddtp</tt>: translations of descriptions and debconf templates
+ <item><tt>derivatives</tt>: changes made on the package by derivative distributions
<item><tt>upload-source</tt>: announce of a new source upload that
has been accepted
<item><tt>upload-binary</tt>: announce of a new binary-only upload (porting)
<tag><tt>keyword [<email>] {+|-|=} <list of keywords></tt>
<item>
Accept (+) or refuse (-) mails classified under the given keyword(s).
- Define the list (=) of accepted keywords.
+ Define the list (=) of accepted keywords. This changes the default set
+ of keywords accepted by a user.
+
+<tag><tt>keywordall [<email>] {+|-|=} <list of keywords></tt>
+<item>
+ Accept (+) or refuse (-) mails classified under the given keyword(s).
+ Define the list (=) of accepted keywords. This changes the set of
+ accepted keywords of all the currently active subscriptions of a user.
<tag><tt>keyword <sourcepackage> [<email>] {+|-|=} <list of keywords></tt>
<item>
the bot.
</taglist>
+ <p>
+The <prgn>pts-subscribe</prgn> command-line utility (from the
+<package>devscripts</package> package) can be handy to temporarily
+subscribe to some packages, for example after having made an
+non-maintainer upload.
+
<sect1 id="pts-mail-filtering">Filtering PTS mails
<p>
Once you are subscribed to a package, you will get the mails sent to
tests the <file>postrm</file> and <file>prerm</file> scripts.
<item>
Remove the package, then reinstall it.
+ <item>
+Copy the source package in a different directory and try unpacking it and
+rebuilding it. This tests if the package relies on existing files outside of
+it, or if it relies on permissions being preserved on the files shipped inside
+the .diff.gz file.
</list>
source tar-file used by <prgn>dpkg-source</prgn> when constructing the
<file>.dsc</file> file and diff to be uploaded <em>must</em> be
byte-for-byte identical with the one already in the archive.
+ <p>
+Please notice that, in non-native packages, permissions on files that are not
+present in the .orig.tar.gz will not be preserved, as diff does not store file
+permissions in the patch.
<sect id="distribution">Picking a distribution
approved by the security team, it needs to be uploaded so that it can
be installed in the archives. For security uploads, the place to
upload to is
-<tt>ftp://security.debian.org/pub/SecurityUploadQueue/</tt> .
+<tt>ftp://security-master.debian.org/pub/SecurityUploadQueue/</tt> .
<p>
Once an upload to the security queue has been accepted, the package
get this wrong, the archive maintainers will reject your upload (due
to lack of corresponding source code).
<p>
-The ``magic'' for a recompilation-only NMU is triggered by using the
-third-level number on the Debian part of the version. For instance,
-if the latest version you are recompiling against was version
-``2.9-3'', your NMU should carry a version of ``2.9-3.0.1''. If the
-latest version was ``3.4-2.1'', your NMU should have a version number
-of ``3.4-2.1.1''.
+The ``magic'' for a recompilation-only NMU is triggered by using a
+suffix appended to the package version number,
+following the form b<number>.
+For instance, if the latest version you are
+recompiling against was version ``2.9-3'', your NMU should carry a
+version of ``2.9-3+b1''. If the latest version was ``3.4+b1'' (i.e, a
+native package with a previous recompilation NMU), your NMU should have
+a version number of ``3.4+b2''.
+
+<footnote>
+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 the
+same package, and has therefore been abandoned in favor of this new
+syntax.</footnote>
<p>
Similar to initial porter uploads, the correct way of invoking
<prgn>dpkg-buildpackage</prgn> is <tt>dpkg-buildpackage -B</tt> to only
package, it must be included in <file>packages-arch-specific</file>, a
list used by the <prgn>wanna-build</prgn> script.
The current version is available as
-<url id="http://cvs.debian.org/srcdep/Packages-arch-specific?rev=HEAD&cvsroot=dak&content-type=text/vnd.viewcvs-markup">;
+<url id="http://cvs.debian.org/srcdep/Packages-arch-specific?cvsroot=dak">;
please see the top of the file for whom to contact for changes.
</list>
<p>
Those delays may be doubled during a freeze, or testing transitions may be
switched off altogether;
<item>
-It must have fewer release-critical bugs than the version currently available
+It must have the same number or fewer release-critical bugs than the version currently available
in <em>testing</em>;
<item>
It must be available on all architectures on which it has previously
the package manager (e.g., "this is the client for the foo server")?
<p>
Be careful to avoid spelling and grammar mistakes. Ensure that you
-spell-check it. <prgn>ispell</prgn> has a special <tt>-g</tt> option
-for <file>debian/control</file> files:
+spell-check it. Both <prgn>ispell</prgn> and <prgn>aspell</prgn>
+have special modes for checking <file>debian/control</file> files:
<example>ispell -d american -g debian/control</example>
+<example>aspell -d en -D -c debian/control</example>
<p>
Users usually expect these questions to be answered in the package
description:
home page from the description to this field, you should probably wait
until that is available.
Please make sure that this line matches the regular expression
- <tt>/^ Homepage: [^ ]*$/<tt>,
+ <tt>/^ Homepage: [^ ]*$/</tt>,
as this allows <file>packages.debian.org</file> to parse it correctly.</p>
</sect1>
</sect>
tracking system.
<p>
It is an old tradition to acknowledge bugs fixed in non-maintainer
-uploads in the first changelog entry of the proper maintainer upload,
-for instance, in a changelog entry like this:
-<example>
- * Maintainer upload, closes: #42345, #44484, #42444.
-</example>
-This will close the NMU bugs tagged "fixed" when the package makes
-it into the archive. The bug for the fact that an NMU was done can be
-closed the same way. Of course, it's also perfectly acceptable to
-close NMU-fixed bugs by other means; see <ref id="bug-answering">.
+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.
</sect1>
<sect1 id="bpp-changelog-errors">
There are two kinds of original source tarballs: Pristine source
and repackaged upstream source.
</p>
- <sect2 id="pristine source">
+ <sect2 id="pristinesource">
<heading>Pristine source</heading>
<p>
The defining characteristic of a pristine source tarball is that the
</enumlist>
</p>
</sect2>
- <sect2 id="repackaged origtargz">
+ <sect2 id="repackagedorigtargz">
<heading>Repackaged upstream source</heading>
<p>
You <strong>should</strong> upload packages with a pristine source
<package>debhelper</package>.
<p>
The consensus is that <package>debmake</package> is now deprecated in
-favor of <package>debhelper</package>. However, it's not a bug to use
-<package>debmake</package>.
+favor of <package>debhelper</package>. It is a bug to use
+<package>debmake</package> in new packages. New packages using
+<package>debmake</package> will be rejected from the archive.
</sect1>
<sect1 id="dh-make">
~ianmdlvl / developers-reference.git / blobdiff