<!ENTITY % dynamicdata SYSTEM "dynamic.ent" > %dynamicdata;
<!-- CVS revision of this document -->
- <!ENTITY cvs-rev "$Revision: 1.296 $">
+ <!ENTITY cvs-rev "$Revision: 1.332 $">
<!-- if you are translating this document, please notate the CVS
revision of the original developer's reference in cvs-en-rev -->
<copyright>
<copyrightsummary>
-copyright © 2004—2006 Andreas Barth</copyrightsummary>
+copyright © 2004—2007 Andreas Barth</copyrightsummary>
<copyrightsummary>
copyright © 1998—2003 Adam Di Carlo</copyrightsummary>
<copyrightsummary>
Quality Assurance (QA) work you can join maintainers already working on
these tasks and submit patches and improvements.
+ <p>
+One pitfall could be a too-generic local part in your mailadress:
+Terms like mail, admin, root, master should be avoided, please
+see <url id="http://www.debian.org/MailingLists/"> for details.
+
<sect id="mentors">Debian mentors and sponsors
<p>
<p>
Before you decide to register with &debian-formal;, you will need to
read all the information available at the <url id="&url-newmaint;"
-name="New Maintainer's Corner">. It describes exactly the
+name="New Maintainer's Corner">. It describes in detail the
preparations you have to do before you can register to become a Debian
developer.
The process of registering as a developer is a process of verifying
your identity and intentions, and checking your technical skills. As
the number of people working on &debian-formal; has grown to over
-&number-of-maintainers; people and our systems are used in several
+&number-of-maintainers; and our systems are used in several
very important places, we have to be careful about being compromised.
Therefore, we need to verify new maintainers before we can give them
accounts on our servers and let them upload packages.
alternative ways to pass the ID check may be permitted
as an absolute exception on a case-by-case-basis.
See the <url id="&url-newmaint-id;" name="identification page">
-for more informations.)
+for more information.)
<p>
If you do not have an OpenPGP key yet, generate one. Every developer
-needs a OpenPGP key in order to sign and verify package uploads. You
+needs an OpenPGP key in order to sign and verify package uploads. You
should read the manual for the software you are using, since it has
much important information which is critical to its security. Many
more security failures are due to human error than to software failure
so this has nothing to do with GnuPG's question about "which kind
of key do you want: (1) DSA and Elgamal, (2) DSA (sign only), (5)
RSA (sign only)". If you don't have any special requirements just pick
-the defailt.
+the default.
<p>
The easiest way to tell whether an existing key is a v4 key or a v3
(or v2) key is to look at the fingerprint:
have an older key you may have to manually add those signatures.
</footnote>
<p>
-If your public key isn't on public key servers such as &pgp-keyserv;,
+If your public key isn't on a public key server such as &pgp-keyserv;,
please read the documentation available at
<url id="&url-newmaint-id;" name="NM Step 2: Identification">.
That document contains instructions on how to put your key on the
issue several calls for votes on &email-debian-devel-announce; (and all
developers are expected to be subscribed to that list). Democracy doesn't
work well if people don't take part in the vote, which is why we encourage
-all developers to vote. Voting is conducted via GPG-signed/encrypted emails
+all developers to vote. Voting is conducted via GPG-signed/encrypted email
messages.
<p>
-The list of all the proposals (past and current) is available on the
+The list of all proposals (past and current) is available on the
<url id="&url-vote;" name="Debian Voting Information"> page, along with
information on how to make, second and vote on proposals.
<p>
It is common for developers to have periods of absence, whether those are
planned vacations or simply being buried in other work. The important thing
-to notice is that the other developers need to know that you're on vacation
+to notice is that other developers need to know that you're on vacation
so that they can do whatever is needed if a problem occurs with your
packages or other duties in the project.
<p>
Usually this means that other developers are allowed to NMU (see
-<ref id="nmu">) your package if a big problem (release critical bugs,
+<ref id="nmu">) your package if a big problem (release critical bug,
security update, etc.) occurs while you're on vacation. Sometimes it's
-nothing as critical as that, but it's still appropriate to let the others
+nothing as critical as that, but it's still appropriate to let others
know that you're unavailable.
<p>
In order to inform the other developers, there are two things that you should do.
All bug reports that have severity <em>critical</em>, <em>grave</em> or
<em>serious</em> are considered to have an impact on whether the package can
be released in the next stable release of Debian.
-Those bugs can delay the Debian release
+These bugs can delay the Debian release
and/or can justify the removal of a package at freeze time. That's why
these bugs need to be corrected as quickly as possible.
<p>
&email-debian-private;.
<item>
Notify the Debian key ring maintainers that you are leaving by
-emailing to &email-debian-keyring;.
+opening a ticket in Debian RT by sending a mail
+to keyring@rt.debian.org with the words 'Debian RT' somewhere in the subject
+line (case doesn't matter).
</enumlist>
posting messages.
<p>
Please read the <url name="code of conduct" id="&url-debian-lists;#codeofconduct">
-for more information.
+for more information. The <url name="Debian Community Guidelines" id="&url-dcg;">
+are also worth reading.
<sect1 id="core-devel-mailing-lists">Core development mailing lists
<p>
reading. Other channels are dedicated to an architecture or a set of
packages: <em>#debian-bsd</em>, <em>#debian-kde</em>, <em>#debian-jr</em>,
<em>#debian-edu</em>,
-<em>#debian-sf</em> (SourceForge package), <em>#debian-oo</em> (OpenOffice
+<em>#debian-oo</em> (OpenOffice
package) ...
<p>
Some non-English developers' channels exist as well, for example
for porting activities, and they all have a permanent connection to the
Internet.
<p>
-Most of the machines are available for individual developers to use,
+Some of the machines are available for individual developers to use,
as long as the developers follow the rules set forth in the
<url name="Debian Machine Usage Policies" id="&url-dmup;">.
<p>
<p>
If you have a problem with the operation of a Debian server, and you
think that the system operators need to be notified of this problem,
-the Debian system administrator team is reachable at
-<email>debian-admin@lists.debian.org</email>.
+you can check the list of open issues in the DSA queue of our request
+tracker at <url id="&url-rt;"> (you can login with user "guest" and
+password "readonly"). To report a new problem, simply send a mail to
+<email>admin@rt.debian.org</email> and make sure to put the string
+"Debian RT" somewhere in the subject.
<p>
If you have a problem with a certain service, not related to the system
administration (such as packages to be removed from the archive,
<sect1 id="servers-ftp-master">The ftp-master server
<p>
The <tt>ftp-master.debian.org</tt> server holds the canonical copy of the Debian
-archive (excluding the non-US packages). Generally, package uploads
+archive. Generally, package uploads
go to this server; see <ref id="upload">.
<p>
It is restricted; a mirror is available on <tt>merkel</tt>.
an email to &email-ftpmaster;, but also see the procedures in
<ref id="archive-manip">.
- <sect1 id="servers-non-us">The non-US server
- <p>
-The non-US server <tt>non-us.debian.org</tt>
-was discontinued with the release of sarge. The pseudo-package
-<package>nonus.debian.org</package>
-stil exists for now.
-
<sect1 id="servers-www">The www-master server
<p>
The main web server is <tt>www-master.debian.org</tt>.
<sect1 id="dchroot">chroots to different distributions
<p>
On some machines, there are chroots to different distributions available.
-You can use them like
+You can use them like this:
<example>
vore% dchroot unstable
<sect1>Architectures
<p>
-In the first days, the Linux kernel was only available for the Intel
-i386 (or greater) platforms, and so was Debian. But when Linux became
+In the first days, the Linux kernel was only available for Intel
+i386 (or greater) platforms, and so was Debian. But as Linux became
more and more popular, the kernel was ported to other architectures,
too.
<p>
contains the sources of the program. If a package is distributed
elsewhere too, the <file>.orig.tar.gz</file> file stores the so-called
<em>upstream source code</em>, that is the source code that's
-distributed from the <em>upstream maintainer</em> (often the author of
+distributed by the <em>upstream maintainer</em> (often the author of
the software). In this case, the <file>.diff.gz</file> contains the
changes made by the Debian maintainer.
<p>
1.1 is called `buzz'; Debian 1.2, `rex'; Debian 1.3, `bo'; Debian 2.0,
`hamm'; Debian 2.1, `slink'; Debian 2.2, `potato'; Debian 3.0, `woody';
Debian 3.1, "sarge";
-Debian (number needs to be determined), "etch".
+Debian 4.0, "etch".
There is also a ``pseudo-distribution'', called `sid', which is the current
`unstable' distribution; since packages are moved from `unstable' to
`testing' as they approach stability, `sid' itself is never released.
until it is really installed
in the Debian archive.
This happens only once a day
-(and is also called `dinstall run' for historical reasons);
+(and is also called the `dinstall run' for historical reasons);
the package
is then removed from incoming and installed in the pool along with all
the other packages. Once all the other updates (generating new
<tag><tt>summary</tt>
<item>
-(This is a planned expansion.)
-The regular summary emails about the package's status (bug statistics,
-porting overview, progression in <em>testing</em>, ...).
+Regular summary emails about the package's status.
+Currently, only progression in <em>testing</em> is sent.
+
</taglist>
<p>
useful information.
<p>
It is a good idea to look up your own data regularly so that
-you don't forget any open bug, and so that you don't forget which
-packages are under your responsibility.
+you don't forget any open bugs, and so that you don't forget which
+packages are your responsibility.
<sect id="alioth">Debian *Forge: Alioth
<p>
changelog of the new package in order for the bug report to be
automatically closed once the new package is installed in the archive
(see <ref id="upload-bugfix">).
+ <p>
+When closing security bugs include CVE numbers as well as the
+"Closes: #nnnnn".
+This is useful for the security team to track vulnerabilities.
+If an upload is made to fix the bug before the advisory ID is known,
+it is encouraged to modify the historical changelog entry with the next upload.
+Even in this case, please include all available pointers to background
+information in the original changelog entry.
+
<p>
There are a number of reasons why we ask maintainers to announce their
intentions:
The announcements give maintainers and other interested parties a
better feel of what is going on, and what is new, in the project.
</list>
-
+ <p>
+Please see <url id="http://ftp-master.debian.org/REJECT-FAQ.html">
+for common rejection reasons for a new package.
<sect id="changelog-entries">Recording changes in the package
<p>
<sect1 id="upload-stable">
<heading>Special case: uploads to the <em>stable</em> distribution</heading>
<p>
-Uploading to <em>stable</em> means that the package will be placed into the
-<file>stable-proposed-updates</file> directory of the Debian archive for further
-testing before it is actually included in <em>stable</em>.
+Uploading to <em>stable</em> means that the package will transfered to the
+<em>p-u-new</em>-queue for review by the stable release managers, and
+if approved will be installed in
+<file>stable-proposed-updates</file> directory of the Debian archive.
+From there, it will be included in <em>stable</em> with the next point release.
<p>
Extra care should be taken when uploading to <em>stable</em>. Basically, a
package should only be uploaded to stable if one of the following happens:
those other packages uninstallable, is strongly discouraged.
<p>
The Release Team (which can be reached at &email-debian-release;) will
-regularly evaluate the uploads in <em>stable-proposed-updates</em> and decide if
+regularly evaluate the uploads To <em>stable-proposed-updates</em> and decide if
your package can be included in <em>stable</em>. Please be clear (and
verbose, if necessary) in your changelog entries for uploads to
<em>stable</em>, because otherwise the package won't be considered for
For removing packages, please see the README file in that ftp directory,
and the Debian package <ref id="dcut">.
- <sect1 id="upload-non-us">Uploading to <tt>non-US</tt>
- <p>
-<em>Note:</em> non-us was discontinued with release of sarge.
-
-
<sect1 id="delayed-incoming">Delayed uploads
<p>
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.
due to the login restrictions on those hosts.
<p>
The anonymous queues on ftp.uni-erlangen.de and ftp.uk.debian.org are
-currently down. Work is underway to resurrect those.
+currently down. Work is underway to resurrect them.
<p>
The queues on master.debian.org, samosa.debian.org, master.debian.or.jp,
and ftp.chiark.greenend.org.uk are down permanently, and will not be
<em>override file</em>.
<p>
To alter the actual section that a package is put in, you need to
-first make sure that the <file>debian/control</file> in your package
+first make sure that the <file>debian/control</file> file in your package
is accurate. Next, send an email &email-override; or submit a bug
against <package>ftp.debian.org</package> requesting that the section
or priority for your package be changed from the old section or
Operations such as reassigning bugs to other packages, merging separate
bug reports about the same issue, or reopening bugs when they are
prematurely closed, are handled using the so-called control mail server.
-All of the commands available in this server are described in the
+All of the commands available on this server are described in the
<url id="&url-bts-control;" name="BTS control server documentation">.
<sect1 id="bug-monitoring">Monitoring bugs
bug log (that means you don't need to send a copy of the mail to
<email>123@&bugs-host;</email>).
<p>
-If you get a bug which mentions "FTBFS", that means "Fails to build
+If you get a bug which mentions "FTBFS", this means "Fails to build
from source". Porters frequently use this acronym.
<p>
Once you've dealt with a bug report (e.g. fixed it), mark it as
the unmerge command, see the BTS control server documentation.
<item>
The bug submitter may have forgotten to provide some information, in which
-case you have to ask them the required information. You may use the
+case you have to ask them for the required information. You may use the
<tt>moreinfo</tt> tag to mark the bug as such. Moreover if you can't
reproduce the bug, you tag it <tt>unreproducible</tt>. Anyone who
can reproduce the bug is then invited to provide more information
Forwarding a bug is not enough, you have to check at each release if
the bug has been fixed or not. If it has, you just close it, otherwise
you have to remind the author about it. If you have the required skills
-you can prepare a patch that fixes the bug and that you send at the
-same time to the author. Make sure to send the patch to the BTS and to
+you can prepare a patch that fixes the bug and
+send it to the author at the same time.
+Make sure to send the patch to the BTS and to
tag the bug as <tt>patch</tt>.
<item>
If you have fixed a bug in your local copy, or if a fix has been
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
-wrongly closed bugs, send an <tt>reopen <var>XXX</var></tt> command to
+wrongly closed bugs, send a <tt>reopen <var>XXX</var></tt> command to
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 the bug number, and
+put "Version: YYY" and an empty line as the first two lines
+of the body of the email,
+where <var>YYY</var> is the first version
+where the bug has been fixed.
+
<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
Due to their sensitive nature, security-related bugs must be handled
carefully. The Debian Security Team exists to coordinate this
activity, keeping track of outstanding security problems, helping
-maintainers with security problems or fix them themselves, sending
+maintainers with security problems or fixing them themselves, sending
security advisories, and maintaining security.debian.org.
<!-- information about the security database goes here once it's ready -->
Useful information includes, for example:
<list compact>
- <item>What versions of the package are known to be affected by the
+ <item>Which versions of the package are known to be affected by the
bug. Check each version that is present in a supported Debian
release, as well as testing and unstable.
whether it is already a matter of public knowledge.
<p>
-There are a few ways developers can learn of a security problem:
+There are several ways developers can learn of a security problem:
<list compact>
<item>they notice it on a public forum (mailing list, web site, etc.)
<item>If the problem is severe, it is preferable to share the
information with
other vendors and coordinate a release. The security team keeps
- contacts with the various organizations and individuals and can take
+ in contact with the various organizations and individuals and can take
care of that.
</list>
<p>
If a member of the security team accepts a package, it will be
-installed on security.debian.org as well as the proper
-<var>distribution</var>-proposed-updates on ftp-master or in the non-US
-archive.
+installed on security.debian.org as well as proposed for the proper
+<var>distribution</var>-proposed-updates on ftp-master.
<sect id="archive-manip">
<heading>Moving, removing, renaming, adopting, and orphaning
<p>
Some archive manipulation operations are not automated in the Debian
upload process. These procedures should be manually followed by
-maintainers. This chapter gives guidelines in what to do in these
+maintainers. This chapter gives guidelines on what to do in these
cases.
<sect1 id="moving-pkgs">Moving packages
If you need to change the section for one of your packages, change the
package control information to place the package in the desired
section, and re-upload the package (see the <url id="&url-debian-policy;"
-name="Debian Policy Manual"> for details). If your new section is
+name="Debian Policy Manual"> for details).
+You must ensure that you include the <file>.orig.tar.gz</file> in your upload
+(even if you are not uploading a new upstream version),
+or it will not appear in the new section together with the rest of the package.
+If your new section is
valid, it will be moved automatically. If it does not, then contact
the ftpmasters in order to understand what happened.
<p>
removed automatically after the package has been removed from
<em>unstable</em> and no package in <em>testing</em> depends on it.
<p>
-You also have to detail the reasons justifying that request. This is to
+There is one exception when an explicit removal request is not necessary:
+If a (source or binary) package is an orphan, it will be removed
+semi-automatically.
+For a binary-package, this means if there is no longer any source package
+producing this binary package;
+if the binary package is just no longer produced on some architectures,
+a removal request is still necessary.
+For a source-package, this means that all binary packages it refers to
+have been taken over by another source package.
+ <p>
+In your removal request, you have to detail the reasons justifying the 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
supersedes the one to be removed.
If you want to remove another package, you have to get the approval
of its maintainer.
<p>
+Further information relating to these and other package removal related
+topics may be found at <url id="http://wiki.debian.org/ftpmaster_Removals"> and
+<url id="http://qa.debian.org/howto-remove.html">.
+ <p>
If in doubt concerning whether a package is disposable, email
&email-debian-devel; asking for opinions. Also of interest is the
<prgn>apt-cache</prgn> program from the <package>apt</package>
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</prgn>.
Removal of orphaned packages is discussed on &email-debian-qa;.
<p>
Once the package has been removed, the package's bugs should be handled.
They should either be reassigned to another package in the case where
the actual code has evolved into another package (e.g. <tt>libfoo12</tt>
was removed because <tt>libfoo13</tt> supersedes it) or closed if the
-software is simply no more part of Debian.
+software is simply no longer part of Debian.
<sect2>Removing packages from <file>Incoming</file>
<p>
<sect1 id="orphaning">Orphaning a package
<p>
-If you can no longer maintain a package, you need to inform the others
-about that, and see that the package is marked as orphaned.
+If you can no longer maintain a package, you need to inform others,
+and see that the package is marked as orphaned.
You should set the package maintainer to <tt>Debian QA Group
&orphan-address;</tt> and submit a bug report
against the pseudo package <package>wnpp</package>. The bug report should be
<sect1 id="adopting">Adopting a package
<p>
-A list of packages in need of a new maintainer is available at in the
+A list of packages in need of a new maintainer is available in the
<url name="Work-Needing and Prospective Packages list (WNPP)"
id="&url-wnpp;">. If you wish to take over maintenance of any of the
packages listed in the WNPP, please take a look at the aforementioned
<sect1 id="porter-automation">
<heading>Porting infrastructure and automation</heading>
<p>
-There is infrastructure and several tools to help automate the package
+There is infrastructure and several tools to help automate package
porting. This section contains a brief overview of this automation and
porting to these tools; see the package documentation or references for
full information.</p>
bounds checking). It will also enable Debian to recompile entire
distributions quickly.
<p>
-The buildds admins of each arch can be contacted by the mail address
+The buildds admins of each arch can be contacted at the mail address
$arch@buildd.debian.org.
<sect1 id="packages-arch-specific">When your package is <em>not</em> portable
See <ref id="buildd"> for some more information.
<p>
The main reason why NMUs are done is when a
-developer needs to fix another developer's packages in order to
+developer needs to fix another developer's package in order to
address serious problems or crippling bugs
or when the package maintainer is unable to release a fix
in a timely fashion.
and accepted.
You should endeavor to reach the current maintainer of the package; they
might be just about to upload a fix for the problem, or have a better
-solution present.
+solution.
<p>
NMUs should be made to assist a package's maintainer in resolving bugs.
Maintainers should be thankful for that help, and NMUers should respect
package in the archive was not made by the official maintainer.
<p>
If there is no <var>debian-revision</var> component in the version
-number then one should be created, starting at `0.1'. If it is
+number then one should be created, starting at `0.1' (but in case
+of a debian native package still upload it as native package).
+If it is
absolutely necessary for someone other than the usual maintainer to
make a release based on a new upstream version then the person making
the release should start with the <var>debian-revision</var> value
<sect1 id="nmu-changelog">
<heading>Source NMUs must have a new changelog entry</heading>
<p>
-A non-maintainer doing a source NMU must create a changelog entry,
+Anyone who is doing a source NMU must create a changelog entry,
describing which bugs are fixed by the NMU, and generally why the NMU
was required and what it fixed. The changelog entry will have the
-non-maintainer's email address in the log entry and the NMU version
-number in it.
+email address of the person who uploaded it in the log entry
+and the NMU version number in it.
<p>
By convention, source NMU changelog entries start with the line
<example>
architectures, then you do a source NMU as usual and you will have to
send a patch.
<p>
-If the source NMU (non-maintainer upload) fixes some existing bugs,
-these bugs should be tagged <em>fixed</em> in the Bug Tracking
-System rather than closed. By convention, only the official package
-maintainer or the original bug submitter close bugs.
-Fortunately, Debian's archive system recognizes NMUs and thus marks
-the bugs fixed in the NMU appropriately if the person doing the NMU
-has listed all bugs in the changelog with the <tt>Closes:
-bug#<var>nnnnn</var></tt> syntax (see <ref id="upload-bugfix"> for
-more information describing how to close bugs via the changelog).
-Tagging the bugs <em>fixed</em> ensures that everyone knows that the
-bug was fixed in an NMU; however the bug is left open until the
-changes in the NMU are incorporated officially into the package by
-the official package maintainer.
+Bugs fixed by source NMUs used to be tagged fixed instead of closed,
+but since version tracking is in place, such bugs are now also
+closed with the NMU version.
<p>
Also, after doing an NMU, you have to send
-that information to the existing bugs that are fixed by your NMU,
+the information to the existing bugs that are fixed by your NMU,
including the unified diff.
-Alternatively you can open a new bug and include a
+Historically, it was custom to open a new bug and include a
patch showing all the changes you have made.
The normal maintainer will either apply the patch or employ an alternate
method of fixing the problem. Sometimes bugs are fixed independently
<p>
Source NMU packages are built normally. Pick a distribution using the
same rules as found in <ref id="distribution">, follow the other
-prescriptions in <ref id="upload">.
+instructions in <ref id="upload">.
<p>
Make sure you do <em>not</em> change the value of the maintainer in
the <file>debian/control</file> file. Your name as given in the NMU entry of
<p>
In any case, you should not be upset by the NMU. An NMU is not a
personal attack against the maintainer. It is a proof that
-someone cares enough about the package and that they were willing to help
+someone cares enough about the package that they were willing to help
you in your work, so you should be thankful. You may also want to
ask them if they would be interested in helping you on a more frequent
basis as co-maintainer or backup maintainer
packages which haven't had their maintainer set correctly is available at
<url id="&url-debian-qa-orphaned;">. If you perform an NMU on an
improperly orphaned package, please set the maintainer to ``Debian QA Group
-<packages@qa.debian.org>''. Also, the bugs are closed in that case,
-and not only marked fixed.
+<packages@qa.debian.org>''.
<sect1 id="nmu-who">Who can do an NMU
<p>
-Only official, registered Debian maintainers can do binary or source
-NMUs. An official maintainer is someone who has their key in the
+Only official, registered Debian Developers can do binary or source
+NMUs. A Debian Developer is someone who has their key in the
Debian key ring. Non-developers, however, are encouraged to download
the source package and start hacking on it to fix problems; however,
rather than doing an NMU, they should just submit worthwhile patches
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''
source NMU rather than a binary-only NMU. As you can see, we don't
distinguish in terminology between porter NMUs and non-porter NMUs.
<p>
-Both classes of NMUs, source and binary-only, can be lumped by the
+Both classes of NMUs, source and binary-only, can be lumped under the
term ``NMU''. However, this often leads to confusion, since most
people think ``source NMU'' when they think ``NMU''. So it's best to
be careful: always use ``binary NMU'' or ``binNMU'' for binary-only
"Collaborative maintenance" is a term describing the sharing of Debian
package maintenance duties by several people. This collaboration is
almost always a good idea, since it generally results in higher quality and
-faster bug fix turnaround time. It is strongly recommended that
+faster bug fix turnaround times. It is strongly recommended that
packages with a priority of <tt>Standard</tt> or which are part of
the base set have co-maintainers.</p>
<p>
Setup the co-maintainer with access to the sources you build the
package from. Generally this implies you are using a network-capable
version control system, such as <prgn>CVS</prgn> or
-<prgn>Subversion</prgn>.</p>
+<prgn>Subversion</prgn>. Alioth (see <ref id="alioth">) provides such
+tools, amongst others.</p>
</item>
<item>
<p>
should subscribe themselves to the appropriate source package.</p>
</item>
</list></p>
- <p>
-Collaborative maintenance can often be further eased with the use of
-tools on Alioth (see <ref id="alioth">).
+ <p>
+Another form of collaborative maintenance is team maintenance, which is
+recommended if you maintain several packages with the same group of
+developers. In that case, the Maintainer and Uploaders field of each
+package must be managed with care. It is recommended to choose between
+one of the two following schemes:
+ <enumlist>
+ <item>
+ <p>
+Put the team member mainly responsible for the package in the Maintainer
+field. In the Uploaders, put the mailing list address, and the team members
+who care for the package.
+ </item>
+ <item>
+ <p>
+Put the mailing list address in the Maintainer field. In the Uploaders
+field, put the team members who care for the package.
+In this case, you must make sure the mailing list accept bug reports
+without any human interaction (like moderation for non-subscribers).
+ </item>
+ </enumlist>
+ <p>
+In any case, it is a bad idea to automatically put all team members in
+the Uploaders field. It clutters the Developer's Package Overview listing
+(see <ref id="ddpo">) with packages one doesn't really care for, and
+creates a false sense of good maintenance.
</sect>
<sect id="testing">
<item>
The packages on which it depends must either be available in <em>testing</em>
or they must be accepted into <em>testing</em> at the same time (and they will
-if they fulfill all the necessary criteria);
+be if they fulfill all the necessary criteria);
</list>
<p>
To find out whether a package is progressing into testing or not, see the
<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>
The packages are looked at to determine whether they are valid
candidates. This gives the "update excuses". The most common reasons
why a package is not considered are too young, RC-bugginess, and out of
-date on some arches. For this part, the release managers have hammers
-of any size to force britney to consider a package. (Also, the base
+date on some arches. For this part of britney,
+the release managers have hammers
+of various sizes to force britney to consider a package. (Also, the base
freeze is coded in that part of britney.) (There is a similar thing
for binary-only updates, but this is not described here. If you're
interested in that, please peruse the code.)
A single source package will often build several binary packages,
either to provide several flavors of the same software (e.g.,
the <package>vim</package> source package) or to make several small
-packages instead of a big one (e.g., if the user can install only the
+packages instead of a big one (e.g., so the user can install only the
subset needed, and thus save some disk space).
<p>
The second case can be easily managed in <file>debian/rules</file>.
<tt>/^ Homepage: [^ ]*$/</tt>,
as this allows <file>packages.debian.org</file> to parse it correctly.</p>
</sect1>
+
+ <sect1 id="bpp-vcs">
+ <heading>Version Control System location</heading>
+ <p>
+There are additional fields for the location of the Version Control System
+in <file>debian/control</file>.
+ <sect2><heading>XS-Vcs-Browser</heading>
+ <p>
+Value of this field should be a <tt>http://</tt> URL pointing to a
+web-browsable copy of the Version Control System repository used to
+maintain the given package, if available.
+ <p>
+The information is meant to be useful for the final user, willing to
+browse the latest work done on the package (e.g. when looking for the
+patch fixing a bug tagged as <tt>pending</tt> in the bug tracking
+system).
+ <sect2><heading>XS-Vcs-*</heading>
+ <p>
+Value of this field should be a string identifying unequivocally the
+location of the Version Control System repository used to maintain the
+given package, if available. <tt>*</tt> identify the Version Control
+System; currently the following systems are supported by the package
+tracking system: <tt>arch</tt>, <tt>bzr</tt> (Bazaar), <tt>cvs</tt>,
+<tt>darcs</tt>, <tt>git</tt>, <tt>hg</tt> (Mercurial), <tt>mtn</tt>
+(Monotone), <tt>svn</tt> (Subversion). It is allowed to specify different
+VCS fields for the same package: they will all be shown in the PTS web
+interface.
+ <p>
+The information is meant to be useful for a user knowledgeable in the
+given Version Control System and willing to build the current version of
+a package from the VCS sources. Other uses of this information might
+include automatic building of the latest VCS version of the given
+package. To this end the location pointed to by the field should better
+be version agnostic and point to the main branch (for VCSs supporting
+such a concept). Also, the location pointed to should be accessible to
+the final user; fulfilling this requirement might imply pointing to an
+anonymous access of the repository instead of pointing to an
+SSH-accessible version of the same.
+ <p>
+In the following example, an instance of the field for a Subversion
+repository of the <package>vim</package> package is shown. Note how the
+URL is in the <tt>svn://</tt> scheme (instead of <tt>svn+ssh://</tt>) and
+how it points to the <file>trunk/</file> branch. The use of the
+<tt>XS-Vcs-Browser</tt> field described above is also shown.
+<example>
+ Source: vim
+ Section: editors
+ Priority: optional
+ <snip>
+ XS-Vcs-Svn: svn://svn.debian.org/svn/pkg-vim/trunk/packages/vim
+ XS-Vcs-Browser: http://svn.debian.org/wsvn/pkg-vim/trunk/packages/vim
+</example>
+ </sect1>
</sect>
<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">
<heading>Common errors in changelog entries</heading>
<p>
-The following examples demonstrate some common errors or example of
+The following examples demonstrate some common errors or examples of
bad style in changelog entries.
<p>
Avoid changing templates too often. Changing templates text induces
more work to translators which will get their translation "fuzzied". If
you plan changes to your original templates, please contact
-translators. Most active translators are very reactive and getting
+translators. Most active translators are very responsive and getting
their work included along with your modified templates will save you
additional uploads. If you use gettext-based templates, the
translator's name and e-mail addresses are mentioned in the po files
You should avoid the use of first person ("I will do this..." or "We
recommend..."). The computer is not a person and the Debconf templates
do not speak for the Debian developers. You should use neutral
-construction and often the passive form. Those of you who already
+construction. Those of you who already
wrote scientific publications, just write your templates like you
would write a scientific paper.
+However, try using action voice if still possible, like
+"Enable this if ..."
+instead of
+"This can be enabled if ...".
<sect2>Be gender neutral
<p>
The world is made of men and women. Please use gender-neutral
-constructions in your writing. This is not Political Correctness, this
-is showing respect to all humanity.
+constructions in your writing.
<sect1>Templates fields definition
<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>error:
<p>
-<strong>THIS TEMPLATE TYPE IS NOT HANDLED BY DEBCONF YET.</strong>
- <p>
-It has been added to cdebconf, the C version of debconf, first used in
-the Debian Installer.
- <p>
-Please do not use it unless debconf supports it.
- <p>
-This type is designed to handle error message. It is mostly similar to
+This type is designed to handle error messages. It is mostly similar to
the "note" type. Frontends may present it differently (for instance,
the dialog frontend of cdebconf draws a red screen instead of the
usual blue one).
+ <p>
+It is recommended to use this type for any message that needs user
+attention for a correction of any kind.
<sect2>Description: short and extended description
should be kept short for improved readability. Do not mix two ideas
in the same paragraph but rather use another paragraph.
<p>
-Don't be too verbose. Some debconf interfaces cannot deal very well
-with descriptions of more than about 20 lines, so try to keep it below
-this limit.
+Don't be too verbose. User tend to ignore too long screens.
+20 lines are by experience a border you shouldn't cross,
+because that means that in the classical dialog interface,
+people will need to scroll, and lot of people just don't do that.
+ <p>
+The extended description should <strong>never</strong> include a question.
<p>
For specific rules depending on templates type (string, boolean,
etc.), please read below.
<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> Again, please avoid referring to specific interface widgets. A common
mistake for such templates is "if you answer Yes"-type
constructions.
<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
<item>
<p>
<strong>must</strong> contain detailed information how
-the repackaged source was obtained, and how this can be reproduced, in
-<file>README.Debian-source</file> or a similar file. This file should
-be in the <file>diff.gz</file> part of the Debian source package,
-usually in the <file>debian</file> directory, <em>not</em> in the
-repackaged <file>orig.tar.gz</file>. It is also a good idea to provide a
+the repackaged source was obtained, and how this can be reproduced
+in the <file>debian/copyright</file>.
+It is also a good idea to provide a
<tt>get-orig-source</tt> target in your <file>debian/rules</file> file
that repeats the process, as described in the Policy Manual, <url
id="&url-debian-policy;ch-source.html#s-debianrules" name="Main
<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>
The file should have a name that makes it clear which binary file it
encodes. Usually, some postfix indicating the encoding should be
appended to the original filename.
+Note that you don't need to depend on <package>sharutils</package> to get
+the <prgn>uudecode</prgn> program if you use <prgn>perl</prgn>'s
+<tt>pack</tt> function.
+The code could look like
+<example>
+uuencode-file:
+ perl -ne 'print(pack "u", $$_);' $(file) > $(file).uuencoded
+
+uudecode-file:
+ perl -ne 'print(unpack "u", $$_);' $(file).uuencoded > $(file)
+</example>
</footnote>.
The file would then be decoded and copied to its place during the
build process. Thus the change will be visible quite easy.
</p>
</sect2>
</sect1>
+ <sect1 id="bpp-dbg">
+ <heading>Best practices for debug packages</heading>
+ <p>
+A debug package is a package with a name ending in "-dbg", that contains
+additional information that gdb can use. Since Debian binaries are
+stripped by default, debugging information, including function names and
+line numbers, is otherwise not available when running gdb on Debian binaries.
+Debug packages allow users who need this additional debugging information to
+install it, without bloating a regular system with the information.
+ <p>
+It is up to a package's maintainer whether to create a debug package or
+not. Maintainers are encouraged to create debug packages for library
+packages, since this can aid in debugging many programs linked to a
+library. In general, debug packages do not need to be added for all
+programs; doing so would bloat the archive. But if a maintainer finds
+that users often need a debugging version of a program, it can be
+worthwhile to make a debug package for it. Programs that are core
+infrastructure, such as apache and the X server are also good candidates
+for debug packages.
+ <p>
+Some debug packages may contain an entire special debugging build of a
+library or other binary, but most of them can save space and build time
+by instead containing separated debugging symbols that gdb can find and
+load on the fly when debugging a program or library. The convention in
+Debian is to keep these symbols in <file>/usr/lib/debug/<em>path</em></file>,
+where <em>path</em> is the path to the executable or library. For example,
+debugging symbols for <file>/usr/bin/foo</file> go in
+<file>/usr/lib/debug/usr/bin/foo</file>, and
+debugging symbols for <file>/usr/lib/libfoo.so.1</file> go in
+<file>/usr/lib/debug/usr/lib/libfoo.so.1</file>.
+ <p>
+The debugging symbols can be extracted from an object file using
+"objcopy --only-keep-debug". Then the object file can be stripped, and
+"objcopy --add-gnu-debuglink" used to specify the path to the debugging
+symbol file. <manref name="objcopy" section="1"> explains in detail how this
+works.
+ <p>
+The dh_strip command in debhelper supports creating debug packages, and
+can take care of using objcopy to separate out the debugging symbols for
+you. If your package uses debhelper, all you need to do is call
+"dh_strip --dbg-package=libfoo-dbg", and add an entry to debian/control
+for the debug package.
+ <p>
+Note that the Debian package should depend on the package that it
+provides debugging symbols for, and this dependency should be versioned.
+For example:
+
+<example>
+Depends: libfoo-dbg (= ${binary:Version})
+</example>
</sect>
will help prevent a situation in which several maintainers start
filing the same bug report simultaneously.
<p>
+Please use the programms <prgn>dd-list</prgn> and
+if appropriate <prgn>whodepends</prgn>
+(from the package devscripts)
+to generate a list of all affected packages, and include the
+output in your mail to &email-debian-devel;.
+ <p>
Note that when sending lots of bugs on the same subject, you should
send the bug report to <email>maintonly@&bugs-host;</email> so
that the bug report is not forwarded to the bug distribution mailing
it is also possible that they just need a reminder.
<p>
There is a simple system (the MIA database) in which information about
-maintainers who are deemed Missing In Action are recorded. When a member of the
+maintainers who are deemed Missing In Action is recorded.
+When a member of the
QA group contacts an inactive maintainer or finds more information about
one, this is recorded in the MIA database. This system is available
in /org/qa.debian.org/mia on the host qa.debian.org, and can be queried
with a tool known as <prgn>mia-query</prgn>.
Use <example>mia-query --help</example> to see how to query the database.
If you find that no information has been recorded
-about an inactive maintainer already, or that you can add more information,
+about an inactive maintainer yet, or that you can add more information,
you should generally proceed as follows.
<p>
-The first step is to politely contact the maintainer, and wait for a
-response for a reasonable time. It is quite hard to define "reasonable
+The first step is to politely contact the maintainer,
+and wait a reasonable time for a response.
+It is quite hard to define "reasonable
time", but it is important to take into account that real life is sometimes
very hectic. One way to handle this would be to send a reminder after two
weeks.
<list>
<item>The "echelon" information available through the
<url id="&url-debian-db;" name="developers' LDAP database">,
- which indicates when the developer last has posted to
+ which indicates when the developer last posted to
a Debian mailing list. (This includes uploads via
debian-*-changes lists.) Also, remember to check whether the
maintainer is marked as "on vacation" in the database.
Please Cc: the person in question.
<p>
Once you have gathered all of this, you can contact &email-mia;.
-People on this alias will use the information you provided in order to
+People on this alias will use the information you provide in order to
decide how to proceed. For example, they might orphan one or all of the
-packages of the maintainer. If a packages has been NMUed, they might prefer
+packages of the maintainer. If a package has been NMUed, they might prefer
to contact the NMUer before orphaning the package — perhaps the person who
has done the NMU is interested in the package.
<p>
One last word: please remember to be polite. We are all volunteers and
cannot dedicate all of our time to Debian. Also, you are not aware of the
circumstances of the person who is involved. Perhaps they might be
-seriously ill or might even had died — you do not know who may be on the
+seriously ill or might even have died — you do not know who may be on the
receiving side. Imagine how a relative will feel if they read the e-mail
of the deceased and find a very impolite, angry and accusing message!
<p>
are available from the Central Debian translation statistics site.
<p>
For general documentation about Debian, the process is more or less the same
-than for the web pages (the translators have access to the CVS), but there are
+as for the web pages (the translators have access to the CVS), but there are
no statistics pages.
<p>
For package-specific documentation (man pages, info documents, other formats),
<list>
<item>
As a maintainer, never edit the translations in any way (even to reformat the
-layout) without asking to the corresponding l10n mailing list. You risk for
-example to break the encoding of the file by doing so. Moreover, what you
-consider as an error can be right (or even needed) in the given language.
+layout) without asking on the corresponding l10n mailing list. You risk for
+example breaksing the encoding of the file by doing so. Moreover, what you
+consider an error can be right (or even needed) in the given language.
<item>
As a translator, if you find an error in the original text, make sure to report
it. Translators are often the most attentive readers of a given text, and if
~ianmdlvl / developers-reference.git / blobdiff