X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?a=blobdiff_plain;f=developers-reference.sgml;h=0745cc39a1b82cbd58d18d7e16fff50165de83f9;hb=324a7fa44e4fbe00fff2164bbd8c8ac740e7f8c4;hp=a4118fbd3303e9a32ef7cf8fa4fff1c9b874bd03;hpb=057fd42386bdc2c5362a5732030935a12af47687;p=developers-reference.git diff --git a/developers-reference.sgml b/developers-reference.sgml index a4118fb..0745cc3 100644 --- a/developers-reference.sgml +++ b/developers-reference.sgml @@ -2,16 +2,15 @@ %versiondata; - + %commondata; - + + - + revision of the original developer's reference in cvs-en-rev --> + FIXME: "> @@ -22,7 +21,8 @@
It should be clear that this reference does not discuss the technical
-details of the Debian package nor how to generate Debian packages.
+details of Debian packages nor how to generate them.
Nor does this reference detail the standards to which Debian software
must comply. All of such information can be found in the
When you have found an advocate, have your GnuPG key signed and have
@@ -256,7 +259,8 @@ but are waiting for your new maintainer application to go through, you
might be able find a sponsor to upload your package for you. Sponsors
are people who are official Debian maintainers, and who are willing to
criticize and upload your packages for you. Those who are seeking a
-sponsor can request one at
If you wish to be a mentor and/or sponsor, more information is
available in .
@@ -333,7 +337,7 @@ 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
know that you're unavailable.
-In order to inform the other developers, there's two things that you should do.
+In order to inform the other developers, there are two things that you should do.
First send a mail to &email-debian-private; with "[VAC] " prepended to the
subject of your message
If you need to modify the upstream sources in order to build a policy
@@ -371,7 +375,7 @@ need, always try not to fork from the upstream sources.
Generally you should deal with bug reports on your packages as described in
. However, there's a special category of bugs that
-you need to take care of -- the so-called release-critical bugs (RC bugs).
+you need to take care of — the so-called release-critical bugs (RC bugs).
All bug reports that have severity critical, grave or
serious are considered to have an impact on whether the package can
be released in the next stable release of Debian.
@@ -590,17 +594,22 @@ administration (such as packages to be removed from the archive,
suggestions for the web site, etc.),
generally you'll report a bug against a ``pseudo-package''. See for information on how to submit bugs.
+
+Some of the core servers are restricted, but the information from there
+is mirror to another server.
&bugs-host; is the canonical location for the Bug Tracking
-System (BTS). If you plan on doing some statistical analysis or
+System (BTS).
+
+It is restricted; a mirror is available on merkel.
+
+If you plan on doing some statistical analysis or
processing of Debian bugs, this would be the place to do it. Please
describe your plans on &email-debian-devel; before implementing
anything, however, to reduce unnecessary duplication of effort or
wasted processing time.
-
-All Debian developers have accounts on &bugs-host;.
@@ -608,6 +617,8 @@ The ftp-master.debian.org server holds the canonical copy of the Debian
archive (excluding the non-US packages). Generally, package uploads
go to this server; see .
+It is restricted; a mirror is available on merkel.
+
Problems with the Debian FTP archive generally need to be reported as
bugs against the
+On some machines, there are chroots to different distributions available.
+You can use them like
+
+
@@ -746,7 +771,7 @@ for installing the Debian distribution on a specific architecture
(
The main section of the Debian archive is what makes up the
official &debian-formal; distribution. The
@@ -887,7 +912,8 @@ distribution changes from day-to-day. Since no special effort is done
to make sure everything in this distribution is working properly, it is
sometimes literally unstable.
-
+Packages are usually installed into the `testing' distribution after they
+have undergone some degree of testing in unstable.
-The scripts that update the testing distribution are run each
-day after the installation of the updated packages. They generate the
-
-The inclusion of a package from unstable is conditional on
-the following:
-
-To find out whether a package is progressing into testing or not, see the
-testing script output on the
-The
-Sometimes, some packages never enter testing because the set of
-inter-relationship is too complicated and cannot be sorted out
-by the scripts. In that case, the release manager must be
-contacted, and he will force the inclusion of the packages.
-
-In general, please refer to the
@@ -1030,7 +1009,10 @@ New software which isn't likely to damage your system can go directly into
An alternative to experimental is to use your personal web space
on people.debian.org.
-
+
+Please consider to use the option -v to
@@ -1141,7 +1123,11 @@ or to move some files back in the
+Note: This description here is currently not working, because
+ftp-master is restricted. Please see for
+the currently working way.
The
-It is conventional that the changelog entry notating of a package that
+It is conventional that the changelog entry of a package that
contains a new upstream version of the software looks like this:
-It is technically possible to upload a package into several distributions
-at the same time but it usually doesn't make sense to use that feature
-because the dependencies of the package may vary with the distribution.
-In particular, it never makes sense to combine the experimental
-distribution with anything else (see ).
+It is not possible to upload a package into several distributions
+at the same time.
-It is discouraged to change anything else in the package that isn't
-important, because even trivial fixes can cause bugs later on.
+Changing anything else in the package that isn't important is discouraged,
+because even trivial fixes can cause bugs later on.
Packages uploaded to stable need to be compiled on systems running
stable, so that their dependencies are limited to the libraries
@@ -1722,50 +1705,32 @@ your package can be included in stable. Please be clear (and
verbose, if necessary) in your changelog entries for uploads to
stable, because otherwise the package won't be considered for
inclusion.
+
+It's best practice to speak with the stable release manager before
+uploading to stable/stable-proposed-updates, so that the
+uploaded package fits the needs of the next point release.
-The testing distribution is fed with packages from unstable according to the rules
-explained in . However, the release manager may stop the testing
-scripts when he wants to freeze the distribution. In that case, you may want to
-upload to testing-proposed-updates to provide fixed packages during the freeze.
-
-Keep in mind that packages uploaded there are not automatically processed, they
-have to go through the hands of the release manager. So you'd better have a good
-reason to upload there. In order to know what a good reason is in the
-release manager's eyes, you should read the instructions that he regularly
-gives on &email-debian-devel-announce;.
-
-You should not upload to testing-proposed-updates when you can update your
-packages through unstable. If you can't (for example because you have a
-newer development version in unstable), you may use it but it is recommended to ask
-the authorization of the release manager before.
+Please see the information in the
-To upload a package, you need a personal account on
-
-If you want to use feature described in ,
-you'll have to upload to ftp-master. It is the only upload
-point that supports delayed incoming.
+To upload a package, you should upload the files (including the signed
+changes and dsc-file) with anonymous ftp to
+
Please note that you should transfer
the changes file last. Otherwise, your upload may be rejected because the
archive maintenance software will parse the changes file and see that not
-all files have been uploaded. If you don't want to bother with transferring
-the changes file last, you can simply copy your files to a temporary
-directory on ftp-master and then move them to
-&us-upload-dir;.
-
+all files have been uploaded.
+
Note: Do not upload to ftp-master cryptographic
packages which belong to contrib or non-free. Uploads of
such software should go to non-us (see ftp-master; depending on the case they may still be uploaded to
You may also find the Debian packages or
useful
-when uploading packages. These handy programs help automate the
+when uploading packages. These handy programs help automate the
process of uploading packages into Debian.
-After uploading your package, you can check how the archive
-maintenance software will process it by running
-Note that
-As discussed above, export controlled software should not be uploaded
-to ftp-master. Instead, upload the package to
-
-You can check your upload the same way it's done on ftp-master,
-with:
-
Note that U.S. residents or citizens are subject to restrictions on
export of cryptographic software. As of this writing, U.S. citizens
@@ -1835,64 +1791,50 @@ advice. Again, it is strongly recommended that U.S. citizens and
residents consult a lawyer before doing uploads to non-US.
-
-If you have a slow network connection to ftp-master, there are
-alternatives. One is to upload files to
-Note: Do not upload packages containing software that is
-export-controlled by the United States government to the queue on
-chiark. Since this upload queue goes to ftp-master, the
-prescription found in applies here as well.
-
-The program
-Another upload queue is available in Germany: just upload the files
-via anonymous FTP to
-The upload must be a complete Debian upload, as you would put it into
-ftp-master's
-There's no need to move your files into a second directory after the
-upload, as on chiark. And, in any case, you should get a
-mail reply from the queue daemon explaining what happened to your
-upload. Hopefully it should have been moved to ftp-master, but in
-case of errors you're notified, too.
+With a fairly recent dput, this section
+
-Note: Do not upload packages containing software that is
-export-controlled by the United States government to the queue on
-erlangen. Since this upload queue goes to ftp-master, the
+Note:
+Since this upload queue goes to ftp-master, the
prescription found in applies here as well.
-
-The program
+Do NOT 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.
+For details, please see section .
-Another upload queue is available which is based in the US, and is a
-good backup when there are problems reaching ftp-master. You can
-upload files, just as in erlangen, to
-An upload queue is available in Japan: just upload the files via
-anonymous FTP to
+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
+resurrected. The queue in Japan will be replaced with a new queue on
+hp.debian.or.jp some day.
+
+For the time being, the anonymous ftp queue on auric.debian.org (the
+former ftp-master) works, but it is deprecated and will be removed at
+some point in the future.
The
-Note also that the term "section" is used for the separation of packages
-according to their licensing, e.g. main, contrib and
-non-free. This is described in another section, .
+Note that the Section field describes both the section as
+well as the subsection, which are described in . If the section is "main", it should be
+omitted. The list of allowable subsections can be found in
-If the bug submitter disagree with your decision to close the bug,
+If the bug submitter disagrees with your decision to close the bug,
they may reopen it until you find an agreement on how to handle it.
If you don't find any, you may want to tag the bug wontfix
to let people know that the bug exists but that it won't be corrected.
@@ -2061,10 +2005,9 @@ the BTS if you wish to keep it reported against your package). Before
doing so, please read the
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
@@ -2072,8 +2015,8 @@ inflate the severity of bugs to make sure their bugs are fixed quickly.
Some bugs may even be dropped to wishlist severity when the requested
change is just cosmetic.
For general information on how to write your changelog entries, see
@@ -2171,8 +2114,10 @@ security advisories, and maintaining security.debian.org.
When you become aware of a security-related bug in a Debian package,
whether or not you are the maintainer, collect pertinent information
about the problem, and promptly contact the security team at
-&email-security-team; as soon as possible. Useful information
-includes, for example:
+&email-security-team; as soon as possible. DO NOT UPLOAD any
+packages for stable; the security team will do that.
+
+Useful information includes, for example:
There are two reasons for releasing information even though secrecy is
-requested: the problem has been known for a while, or that the problem
+requested: the problem has been known for a while, or the problem
or exploit has become public.
+Do NOT include any changes in your package which are
+not directly related to fixing the vulnerability. These will only
+need to be reverted, and this wastes time. If there are other bugs in
+your package that you would like to fix, make an upload to
+proposed-updates in the usual way, after the security advisory is
+issued. The security update mechanism is not a means for introducing
+changes to your package which would otherwise be rejected from the
+stable release, so please do not attempt to do this.
+
Review and test your changes as much as possible. Check the
differences from the previous version repeatedly
(
-When packaging the fix, keep the following points in mind:
+Be sure to verify the following items:
-Usually you only ask the removal of a package maintained by yourself.
+Usually you only ask for the removal of a package maintained by yourself.
If you want to remove another package, you have to get the approval
-of its last maintainer.
+of its maintainer.
If in doubt concerning whether a package is disposable, email
&email-debian-devel; asking for opinions. Also of interest is the
@@ -2473,6 +2430,7 @@ If in doubt concerning whether a package is disposable, email
package. When invoked as apt-cache showpkg
package, the program will show details for
package, including reverse depends.
+Removal of orphaned packages is discussed on &email-debian-qa;.
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
@@ -2485,7 +2443,7 @@ software is simply no more part of Debian.
In the past, it was possible to remove packages from
-Sometimes you made a mistake naming the package and you need to rename
-it. In this case, you need to follow a two-step process. First, set
+When you make a mistake naming your package, you should follow a two-step
+process to rename it. First, set
your
-If the package is especially crucial to Debian, you should instead submit
+If you just intend to give the package away, but you can keep maintainership
+for the moment, then you should instead submit
a bug against
-Read instructions on the
@@ -2579,7 +2537,7 @@ portability. Therefore, even if you are not a porter, you should read
most of this chapter.
Porting is the act of building Debian packages for architectures that
-is different from the original architecture of the package
+are different from the original architecture of the package
maintainer's binary package. It is a unique and essential activity.
In fact, porters do most of the actual compiling of Debian packages.
For instance, for a single i386 binary package, there must be
@@ -2596,7 +2554,7 @@ the case. This section contains a checklist of ``gotchas'' often
committed by Debian maintainers — common problems which often stymie
porters, and make their jobs unnecessarily difficult.
-The first and most important watchword is to respond quickly to bug or
+The first and most important thing is to respond quickly to bug or
issues raised by porters. Please treat porters with courtesy, as if
they were in fact co-maintainers of your package (which in a way, they
are). Please be tolerant of succinct or even unclear bug reports,
@@ -2645,7 +2603,7 @@ They should be removed by the `clean' target of
Make sure you don't rely on locally installed or hacked configurations
or programs. For instance, you should never be calling programs in
+If you are working on a Debian machine for your porting efforts and you
+need to sign your upload locally for the acceptance in the archive, you
+can run
+You have to make sure that your binary-only NMU doesn't render the package
+uninstallable. This could happen when a source package generates
+arch-dependend and arch-independend packages that depend on each other via
+$(Source-Version).
+
+Despite the
required modification of the changelog, these are called binary-only NMUs
— there is no need in this case to trigger all other architectures
to consider themselves out of date or requiring recompilation.
@@ -2710,6 +2681,10 @@ 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''.
+
+Similar to initial porter uploads, the correct way of invoking
+
-However, if you are a porter doing an NMU for `unstable', the above
+If you are a porter doing an NMU for `unstable', the above
guidelines for porting should be followed, with two variations.
Firstly, the acceptable waiting period — the time between when the
bug is submitted to the BTS and when it is OK to do an NMU — is seven
@@ -2739,6 +2708,8 @@ days for porters working on the unstable distribution. This period
can be shortened if the problem is critical and imposes hardship on
the porting effort, at the discretion of the porter group. (Remember,
none of this is Policy, just mutually agreed upon guidelines.)
+For uploads to stable or testing, please coordinate with the appropriate
+release team first.
Secondly, porters doing source NMUs should make sure that the bug they
submit to the BTS should be of severity `serious' or greater. This
@@ -2758,7 +2729,7 @@ Porters may also have an unofficial location where they can put the
results of their work during the waiting period. This helps others
running the port have the benefit of the porter's work, even during
the waiting period. Of course, such locations have no official
-blessing or status, so buyer, beware.
+blessing or status, so buyer beware.
Under certain circumstances it is necessary for someone other than the
-official package maintainer to make a release of a package. This is
+official package maintainer to make a release of a package. This is
called a non-maintainer upload, or NMU.
-Debian porters, who compile packages for different architectures,
-occasionally do binary-only NMUs as part of their porting activity
-(see ). Another reason why NMUs are done is when a
-Debian developers needs to fix another developers' packages in order to
-address serious security problems or crippling bugs, especially during
-the freeze, or when the package maintainer is unable to release a fix
+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 .
+For buildd uploads (which are strictly speaking also NMUs), please see .
+
+The main reason why NMUs are done is when a
+developer needs to fix another developer's packages in order to
+address serious problems or crippling bugs
+or when the package maintainer is unable to release a fix
in a timely fashion.
-
-This chapter contains information providing guidelines for when and
-how NMUs should be done. A fundamental distinction is made between
-source and binary-only NMUs, which is explained in the next section.
-
-
-There are two new terms used throughout this section: ``binary-only NMU''
-and ``source NMU''. These terms are used with specific technical
-meaning throughout this document. Both binary-only and source NMUs are
-similar, since they involve an upload of a package by a developer who
-is not the official maintainer of that package. That is why it's a
-non-maintainer upload.
-
-A source NMU is an upload of a package by a developer who is not the
-official maintainer, for the purposes of fixing a bug in the package.
-Source NMUs always involves changes to the source (even if it is just
-a change to
-A binary-only NMU is a recompilation and upload of a binary package
-for a given architecture. As such, it is usually part of a porting
-effort. A binary-only NMU is a non-maintainer uploaded binary version
-of a package, with no source changes required. There are many cases
-where porters must fix problems in the source in order to get them to
-compile for their target architecture; that would be considered a
-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.
+First and foremost, it is critical that NMU patches to source should
+be as non-disruptive as possible. Do not do housekeeping tasks, do
+not change the name of modules or files, do not move directories; in
+general, do not fix things which are not broken. Keep the patch as
+small as possible. If things bother you aesthetically, talk to the
+Debian maintainer, talk to the upstream maintainer, or submit a bug.
+However, aesthetic changes must not be made in a non-maintainer
+upload.
-Both classes of NMUs, source and binary-only, can be lumped by 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. In this chapter, if we use the unqualified term ``NMU'',
-we refer to any type of non-maintainer upload NMUs, whether source and
-binary, or binary-only.
+And please remember the Hippocratic Oath: "Above all, do no harm."
+It is better if a package has an grave bug open, than if a not working
+patch was applied, and the bug is only hidden now but not resolved.
-
-Only official, registered Debian maintainers can do binary or source
-NMUs. An official maintainer 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.
-
-
-
-Guidelines for when to do a source NMU depend on the target
-distribution, i.e., stable, unstable, or experimental. Porters have
-slightly different rules than non-porters, due to their unique
-circumstances (see ).
+NMUs should be made to assist a package's maintainer in resolving bugs.
+Maintainers should be thankfull for that help, and NMUers should respect
+the decisions of maintainers, and try to personally help the maintainer by
+their work.
-When a security bug is detected, the security team may do an NMU.
-Please refer to for more information.
-
-During the release cycle (see ), NMUs which fix
-serious or higher severity bugs are encouraged and accepted. Even
-during this window, however, you should endeavor to reach the current
-maintainer of the package; they might be just about to upload a fix
-for the problem. As with any source NMU, the guidelines found in need to be followed. Special exceptions are made
-for .
-
-Uploading bug fixes to unstable by non-maintainers should only be done
-by following this protocol:
+A NMU should follow all conventions, written down in this section.
+For an upload to testing or unstable, this order of steps is recommended:
-The following applies to porters insofar as they are playing the dual
-role of being both package bug-fixers and package porters. If a
-porter has to change the Debian source archive, automatically their
-upload is a source NMU and is subject to its rules. If a porter is
-simply uploading a recompiled binary package, the rules are different;
-see .
+For the testing distribution, the rules may be changed by the release
+managers. Please take additional care, and acknowledge that the usual way
+for a package to enter testing is through unstable.
-First and foremost, it is critical that NMU patches to source should
-be as non-disruptive as possible. Do not do housekeeping tasks, do
-not change the name of modules or files, do not move directories; in
-general, do not fix things which are not broken. Keep the patch as
-small as possible. If things bother you aesthetically, talk to the
-Debian maintainer, talk to the upstream maintainer, or submit a bug.
-However, aesthetic changes must not be made in a non-maintainer
-upload.
+For the stable distribution, please take extra care. Of course, the release
+managers may also change the rules here. Please verify before upload that
+all your changes are ok for inclusion into the next stable release by the
+release manager.
+
+When a security bug is detected, the security team may do an NMU, using
+their own rules. Please refer to for more
+information.
+
Maintainers other than the official package maintainer should make as
few changes to the package as possible, and they should always send a
@@ -3023,7 +2965,7 @@ send a patch.
If the source NMU (non-maintainer upload) fixes some existing bugs,
these bugs should be tagged fixed in the Bug Tracking
System rather than closed. By convention, only the official package
-maintainer or the original bug submitter are allowed to close bugs.
+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 Closes:
@@ -3034,9 +2976,11 @@ 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.
-Also, after doing an NMU, you have to open a new bug and include a
-patch showing all the changes you have made. Alternatively you can send
-that information to the existing bugs that are fixed by your NMU.
+Also, after doing an NMU, you have to send
+that 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
+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
upstream, which is another good reason to back out an NMU's patch.
@@ -3048,7 +2992,7 @@ In addition, the normal maintainer should always retain the
entry in the changelog file documenting the non-maintainer upload.
-
Source NMU packages are built normally. Pick a distribution using the
same rules as found in , follow the other
@@ -3064,8 +3008,11 @@ changes file.
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 -v option of
@@ -3073,10 +3020,61 @@ 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
you in your work, so you should be thankful. You may also want to
-ask them if they would be interested to help you on a more frequent
+ask them if they would be interested in helping you on a more frequent
basis as co-maintainer or backup maintainer
(see ).
+
+Unless you know the maintainer is still active, it is wise to check the
+package to see if it has been orphaned. The current list of orphaned
+packages which haven't had their maintainer set correctly is available at
+
+Only official, registered Debian maintainers can do binary or source
+NMUs. An official maintainer 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.
+
+
+There are two new terms used throughout this section: ``binary-only NMU''
+and ``source NMU''. These terms are used with specific technical
+meaning throughout this document. Both binary-only and source NMUs are
+similar, since they involve an upload of a package by a developer who
+is not the official maintainer of that package. That is why it's a
+non-maintainer upload.
+
+A source NMU is an upload of a package by a developer who is not the
+official maintainer, for the purposes of fixing a bug in the package.
+Source NMUs always involves changes to the source (even if it is just
+a change to
+A binary-only NMU is a recompilation and upload of a binary package
+for a given architecture. As such, it is usually part of a porting
+effort. A binary-only NMU is a non-maintainer uploaded binary version
+of a package, with no source changes required. There are many cases
+where porters must fix problems in the source in order to get them to
+compile for their target architecture; that would be considered a
+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.
+
+Both classes of NMUs, source and binary-only, can be lumped by 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. Best use always ``binary NMU'' or ``binNMU'' for binary-only
+NMUs.
+
Generally there is a primary maintainer and one or more
-co-maintainers. The primary maintainer is the whose name is listed in
+co-maintainers. The primary maintainer is the person whose name is listed in
the Maintainer field of the
@@ -3124,6 +3122,251 @@ Collaborative maintenance can often be further eased with the use of
tools on Alioth (see ).
+
+Packages are usually installed into the `testing' distribution after they
+have undergone some degree of testing in unstable.
+
+They must be in sync on all architectures and
+mustn't have dependencies that make them uninstallable; they also have to
+have generally no known release-critical bugs at the time they're
+installed into testing.
+This way, `testing' should always be close to being a release candidate.
+Please see below for details.
+
+The scripts that update the testing distribution are run each
+day after the installation of the updated packages. They generate the
+
+The inclusion of a package from unstable is conditional on
+the following:
+
+To find out whether a package is progressing into testing or not, see the
+testing script output on the
+The
+Sometimes, some packages never enter testing because the set of
+inter-relationship is too complicated and cannot be sorted out
+by the scripts. See below for details.
+
+Some further dependency analysis is shown on
+
+For the testing migration script, "outdated" means: There are different
+versions in unstable for the release architectures (except for the
+architectures in fuckedarches; fuckedarches is an list of architectures
+that don't keep up (in update_out.py), but currently, it's empty).
+"outdated" has nothing whatsoever to do with the architectures this package
+has in testing.
+
+Consider this example:
+
+
+The package is out of date on alpha in unstable, and will not go to
+testing. And removing foo from testing would not help at all, the package
+is still out of date on alpha, and will not propagate to testing.
+
+However, if ftp-master removes a package in unstable (here on arm):
+
+
+In this case, the package is up to date on all release architectures in
+unstable (and the extra hurd-i386 doesn't matter, as it's not a release
+architecture).
+
+Sometimes, the question is raised if it is possible to allow packages in
+that are not yet built on all architectures: No. Just plainly no. (Except
+if you maintain glibc or so.)
+
+
+Sometimes, a package is removed to allow another package in: This happens
+only to allow _another_ package to go in, that's ready in every other
+sense. Consider e.g. that a conflicts with the new version of b; than a may
+be removed to allow b in.
+
+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).
+
+
+A situation that is not handled very well by britney is if package a
+depends on the new version of package b, and vice versa.
+
+An example of this is:
+
+
+Package a is not considered for update, and package b also not.
+
+Currently, this requires some manual hinting from the release team.
+Please, contact them by sending mail to &email-debian-release; if that
+happens to one of your packages.
+
+
+
+Generally, there is nothing that the status of a package in testing means
+for transition of the next version from unstable to testing, with two
+exceptions: If the RC-bugginess of the package goes down, it may go in
+even if it is still RC-buggy. The second exception is if the version
+of the package in testing is out of sync on the different arches: Then
+any arch might just upgrade to the version of the source package;
+however, this can happen only if the package was previously forced
+through, the arch is in fuckedarches or there was no binary package of that
+arch present in unstable at all during the testing migration.
+
+In summary this means: The only influence that a package being in testing
+has on a new version of the same package is that the new version might
+go in easier.
+
+
+If you are interested in details, this is how britney works:
+
+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
+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
+interessted in that, please use the code.)
+
+Now, the more complex part happens: Britney tries to update testing with
+the valid candidates; first, each package alone, and then larger and even
+larger sets of packages together. Each try is accepted if sarge is not
+more uninstallable after the update as before. (Before and after this part,
+some hints are processed; but as only release masters can hint, this is
+probably not so important for you.)
+
+If you want to see more details, you can look it up on
+merkel:/org/ftp.debian.org/testing/update_out/ (or there in
+~aba/testing/update_out to see a setup with a smaller packages file). Via
+web, it's at
+The hints are available via
+The testing distribution is fed with packages from unstable according to the rules
+explained above. However, in some cases, it is necessary to upload
+packages built only for testing. For that, you may want to
+upload to testing-proposed-updates.
+
+Keep in mind that packages uploaded there are not automatically processed, they
+have to go through the hands of the release manager. So you'd better have a good
+reason to upload there. In order to know what a good reason is in the
+release manager's eyes, you should read the instructions that he regularly
+gives on &email-debian-devel-announce;.
+
+You should not upload to testing-proposed-updates when you can update your
+packages through unstable. If you can't (for example because you have a
+newer development version in unstable), you may use it but it is recommended to ask
+the authorization of the release manager before. Even if a package is
+frozen, updates through unstable are possible, if the upload via unstable
+does not pulls an new dependency in.
+
+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.
+
+
+
+
+
+All bugs of some higher severities are by default considered release-critical; currently, these are critical, grave and serious bugs.
+
+Such bugs are presumed to have an impact on the chances that the package will be released with the stable release of Debian: in general, if a package has open release-critical bugs filed on it, it won't get into "testing", and consequently won't be released in "stable".
+
+The "testing" bug count for a package is considered to be roughly the bug count at the last point when the "testing" version equalled the "unstable" version. The bugs tagged woody or sarge will not be counted. Bugs with the sid tag will be counted, though.
+
+
+
+The structure of the distribution archives is such that they can only contain one version of a package; a package is defined by its name. So, when the source package acmefoo is installed into "testing", along with its binary packages acme-foo-bin, acme-bar-bin, libacme-foo1 and libacme-foo-dev, the old version is removed.
+
+However, the old version may have provided a binary package with an old soname of a library, such as libacme-foo0. Removing the old acmefoo will remove libacme-foo0, which will break any packages which depend on it.
+
+Evidently, this mainly affects packages which provide changing sets of binary packages in different versions (in turn, mainly libraries). However, it will also affect packages upon which versioned dependencies have been declared of the ==, <= or << varieties.
+
+When the set of binary packages provided by a source package change in this way, all the packages that depended on the old binaries will have to be updated to depend on the new binaries instead. Because installing such a source package into "testing" breaks all the packages that depended on it in "testing", some care now has to be taken: all the depending packages must be updated and ready to be installed themselves so that they won't be broken, and, once everything is ready, manual intervention by the release manager or an assistant is normally required.
+
+If you are having problems with complicated groups of packages like this, contact debian-devel or debian-release for help.
+
Big, complex packages may have many bugs that you need to deal with.
-If you correct a number of bug directly in the source, if you're not
+If you correct a number of bugs directly in the source, and you're not
careful, it can get hard to differentiate the various patches that you
applied. It can get quite messy when you have to update the package
to a new upstream version which integrates some of the fixes (but not
@@ -3371,6 +3614,32 @@ spell-check it.
+User usually expect these questions to be answered in the package
+description.
+
+Important news about changes in a package can also be put in NEWS.Debian
+files. The news will be displayed by tools like apt-listchanges, before
+all the rest of the changelogs. This is the preferred means to let the user
+know about significant changes in a package. It is better than using
+debconf notes since it is less annoying and the user can go back and refer
+to the NEWS.Debian file after the install. And it's better than listing
+major changes in README.Debian, since the user can easily miss such notes.
+
+The file format is the same as a debian changelog file, but leave off
+the asterisks and describe each news item with a full paragraph when
+necessary rather than the more concise summaries that would go in a
+changelog. It's a good idea to run your file through dpkg-parsechangelog to
+check its formatting as it will not be automatically checked during build
+as the changelog is. Here is an example of a real NEWS.Debian file:
+
+The NEWS.Debian file is installed as
+/usr/share/doc/<package>/NEWS.Debian.gz. It is compressed, and
+always has that name even in Debian native packages. If you use debhelper,
+dh_installchangelogs will install debian/NEWS files for you.
+
+Unlike changelog files, you need not update NEWS.Debian files with every
+release. Only update them if you have something particularly newsworthy
+that user should know about. If you have no news at all, there's no need
+to ship a NEWS.Debian file in your package. No news is good news!
-
-
In the first two cases, the information is public and it is important
@@ -2243,7 +2188,7 @@ itself is public, and can (and will) be examined by the general public.
-
+
+
+
+