X-Git-Url: https://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?a=blobdiff_plain;f=developers-reference.sgml;h=3cc79e0b7370435abaa980bd5dd4e8e78a1f9941;hb=534c5e12049a8d5c43a8c6912cfb74b27273e564;hp=13f2368ce266b9117e079a85b9742f60af4b0170;hpb=51521555be3ad4f8da4c287ce6afd155a588315c;p=developers-reference.git diff --git a/developers-reference.sgml b/developers-reference.sgml index 13f2368..3cc79e0 100644 --- a/developers-reference.sgml +++ b/developers-reference.sgml @@ -5,7 +5,7 @@ %commondata; - + @@ -48,11 +48,10 @@ This is distributed in the hope that it will be useful, but merchantability or fitness for a particular purpose. See the GNU General Public License for more details.
-A copy of the GNU General Public License is available as
-
@@ -99,22 +98,19 @@ Debianize your favourite piece of software. How do you actually
become a Debian developer so that your work can be incorporated into
the Project?
-Firstly, subscribe to
-You should subscribe and lurk for a bit before doing any coding, and
-you should post about your intentions to work on something to avoid
-duplicated effort.
+You should subscribe and lurk (that is, read without posting) for a
+bit before doing any coding, and you should post about your intentions
+to work on something to avoid duplicated effort.
-Another good list to subscribe to is
-
-Registration requires that the following information be sent to
-
-If you do not have a PGP key yet, generate one. Every developer needs
-a PGP key in order to sign and verify package uploads. You should read
-the PGP manual, 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 or high-powered spy techniques.
-
-Our standard is to use
-Your PGP key must be at least 1024 bits long. There is no reason to
-use a smaller key, and doing so would be much less secure. Your key
-must be signed with at least your own user ID. This prevents user ID
-tampering. You can do it by executing pgp -ks
-your_userid.
-
-If your PGP key isn't on public key servers such as
-&pgp-keyserv;, please read the documentation available
-locally /usr/doc/pgp/keyserv.doc. That document contains
-instructions on how to put your key on the public key servers. The
-New Maintainer Group will put your public key on the servers if it
-isn't already there.
+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
+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
+or high-powered spy techniques. See for more
+information on maintaining your public key.
+
+Debian uses the
+The recommended public key algorithm for use in Debian development
+work is the DSA (sometimes call ``DSS'' or ``DH/ElGamal''). Other key
+types may be used however. Your key length must be at least 1024
+bits; there is no reason to use a smaller key, and doing so would be
+much less secure. Your key must be signed with at least your own user
+ID; this prevents user ID tampering.
+Also remember that one of the names on your key must match the email
+address you list as the official maintainer for your packages. For
+instance, I set the maintainer of the
+
+If your public key isn't on public key servers such as &pgp-keyserv;,
+please read the documentation available locally in &file-keyservs;.
+That document contains instructions on how to put your key on the
+public key servers. The New Maintainer Group will put your public key
+on the servers if it isn't already there.
Due to export restrictions by the United States government some Debian
-packages, including PGP, have been moved to an ftp site outside of the
-United States. You can find the current locations of those packages on
-
Some countries restrict the use of cryptographic software by their
citizens. This need not impede one's activities as a Debian package
@@ -226,55 +230,143 @@ then please contact us so we can make special arrangements.
Once you have all your information ready, and your public key is
available on public key servers, send a message to
-
+For more details, please consult
Once this information is received and processed, you should be
contacted with information about your new Debian maintainer account.
-If you don't hear anything within 7-14 days, please send a followup
+If you don't hear anything within a month, please send a followup
message asking if your original application was received. Do
not re-send your original application, that will just confuse
-the new-maintainer team. Please be patient, especially near release
+the New Maintainer Group. Please be patient, especially near release
points; mistakes do occasionally happen, and people do sometimes run
out of volunteer time.
-A mailing list called
Those who prefer one-on-one help (e.g., via private email) should also
post to that list and an experienced developer will volunteer to help.
-
+There's a LDAP database containing many informations concerning all
+developers, you can access it at
+You have to keep the information available there up to date.
Be very careful with your private keys. Do not place them on any
-public servers. Back them up. Read the documentation that comes with
-your software (either PGP or GNUPG); read the FAQs too, for good
-measure.
+public servers or multiuser machines, such as
+master.debian.org. Back your keys up; keep a copy offline.
+Read the documentation that comes with your software; read the
-If you add or remove signatures from your public key, or add or remove
-user identities, you need to update the key servers and mail your
-public key to
You can find a more in-depth discussion of Debian key maintenance in
the documentation for the
+Most developers take vacations, and usually this means that they can't
+work for Debian and they can't be reached by email if any problem occurs.
+The other developers need to know that you're on vacation so that they'll
+do whatever is needed when such a problem occurs. Usually this means that
+other developers are allowed to NMU (see ) your package if a
+big problem (release critical bugs, security update, ...) occurs while
+you're on vacation.
+
+In order to inform the other developers, there's two things that you should do.
+First send a mail to &email-debian-private; giving the period of time when
+you will be on vacation. You can also give some special instructions on what to
+do if any problem occurs. Next you should update your information
+available in the Debian LDAP database and mark yourself as ``on vacation''
+(this information is only accessible to debian developers). Don't forget
+to remove the ``on vacation'' flag when you come back.
+
+
+A big part of your job as Debian maintainer will be to stay in contact
+with the upstream developers since you'll have to share information that
+you get from the Bug Tracking System. It's not your job to fix non-Debian
+specific bugs.
+Rather, you have to forward these bugs to the upstream developers.
+(Of course, if you are able to do so, you may certainly fix them...)
+This way, the bug will hopefully
+be corrected when the next upstream version comes out.
+
+From time to
+time, you may get a patch attached to a bug report. You have to send the
+patch upstream and make sure that it gets included (if the authors accept
+the proposed fix). If you need to modify the upstream sources in order to
+build a policy conformant package, then you should propose a nice fix
+to the upstream developers which can be included there, so that you won't have to
+modify the sources of the next upstream version. Whatever changes you
+need, always try not to fork from the upstream sources.
+
+
+Release Critical Bugs (RCB) are all bugs that have severity
+critical, grave or serious.
+Those bugs can delay the Debian release
+and/or can justify the removal of a package at freeze time. That's why
+those bugs needs to be corrected as fast as possible. You must be
+aware that some developers who are part of the
+Even though there is a dedicated group of people for Quality
+Assurance, QA duties are not reserved solely to them. You can
+participate in this effort by keeping your packages as bug free as
+possible, and as lintian-clean (see ) as
+possible. If you think that it's quite impossible, then you should
+consider orphaning (see ) some of your packages so
+that you can do a good job with the other packages that you
+maintain. Alternatively you may ask the help of other people in order
+to catch up the backlog of bugs that you have (you can ask for help on
+&email-debian-qa; or &email-debian-devel;).
+
If you choose to leave the Debian project, you should make sure you do
@@ -284,10 +376,10 @@ the following steps:
Orphan all your packages, as described in .
-The mailing list server is at lists.debian.org. Mail
-debian-foo-REQUEST@lists.debian.org, where
+The mailing list server is at &lists-host;. Mail
+debian-foo-REQUEST@&lists-host;, where
debian-foo is the name of the list, with the word
subscribe in the Subject to subscribe to the list or
unsubscribe to unsubscribe. More detailed instructions on
how to subscribe and unsubscribe to the mailing lists can be found at
When replying to messages on the mailing list, please do not send a
carbon copy (CC) to the original poster unless they explicitly
request to be copied. Anyone who posts to a mailing list should read
it to see the responses.
-In addition, all messages should usually only be sent to one of the
-following mailing lists:
-
+&email-debian-email; is a special mailing list used as a grab-bag
+for Debian related correspondence such as contacting upstream authors
+about licenses, bugs, etc. or discussing the project with others where it
+might be useful to have the discussion archived somewhere.
As ever on the net, please trim down the quoting of articles you're
replying to. In general, please adhere to the usual conventions for
posting messages.
Online archives of mailing lists are available at
@@ -345,86 +441,83 @@ Debian servers are well known servers which serve critical functions
in the Debian project. Every developer should know what these servers
are and what they do.
-If you have a problem with the operation of Debian server, and you
+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,
-please find the contact address for the particular role at
-The master server, master.debian.org, holds the canonical copy
-of the Debian archive (excluding the non-U.S. packages). Generally,
-package uploads go to this server; see .
-
master.debian.org is the canonical location for the Bug
Tracking System (BTS). 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
-
-All Debian developers have accounts on master.debian.org. Please
-take care to protect your password to this machine. Try to avoid
-login or upload methods which send passwords over the Internet in the
-clear.
-
-If you find a problem with master.debian.org such as disk full,
-suspicious activity, or whatever, send an email to
-
+If you find a problem with master.debian.org such as disk
+full, suspicious activity, or whatever, send an email to
+&email-debian-admin;.
+
+
+The ftp-master server, ftp-master.debian.org (or
+auric.debian.org), holds the canonical copy of the Debian
+archive (excluding the non-U.S. packages). Generally, package uploads
+go to this server; see .
+
+Problems with the Debian FTP archive generally need to be reported as
+bugs against the
The main web server, www.debian.org, is also known as
-va.debian.org. All developers are given accounts on this
+klecker.debian.org. All developers are given accounts on this
machine.
If you have some Debian-specific information which you want to serve
-up on the web, you can do do this by putting material in the
-
If you find a problem with the Debian web server, you should generally
submit a bug against the pseudo-package,
-cvs.debian.org is also known as va.debian.org,
-discussed above. If you need the use of a publically accessible CVS
+cvs.debian.org is also known as klecker.debian.org,
+discussed above. If you need to use a publically accessible CVS
server, for instance, to help coordinate work on a package between
many different developers, you can request a CVS area on the server.
Generally, cvs.debian.org offers a combination of local CVS
access, anonymous client-server read-only access, and full
client-server access through
To request a CVS area, send a request via email to
-
The main web page listing the available public FTP (and, usually,
-HTTP) servers can be found at
Note that mirrors are generally run by third-parties who are
interested in helping Debian. As such, developers generally do not
have accounts on these machines.
-
-Please do not mirror off of master.debian.org. This host
-already has too much load. Check the sites above for information, or
-email
-Aside from the servers mentioned in , the
-following machines are, or may be made, available to you. If an email
-address is listed, generally that person is the party to contact about
-issues on the machine. Otherwise, the machine is probably managed by
-
-Here is an example directory tree of a complete Debian distribution:
+Here is an example directory tree of a complete Debian archive:
&sample-dist-dirtree;
-As you can see, the top-level directory of the distribution contains
-three directories, namely main, contrib, and
-non-free. These directories are called sections.
-
-In each section, there is a directory with the source packages
-(source), a directory for each supported architecture
+As you can see, the top-level directory contains two directories,
+dists/ and pool/. The latter is a ``pool'' in which the
+packages actually are, and which is handled by the archive maintenance
+database and the accompanying programs. The former contains the
+distributions, stable, testing and unstable.
+Each of those distribution directories is divided in equivalent
+subdirectories purpose of which is equal, so we will only explain how it
+looks in stable. The Packages and Sources files in the
+distribution subdirectories can reference files in the pool/
+directory.
+
+dists/stable contains three directories, namely main,
+contrib, and non-free.
+
+In each of the areas, there is a directory with the source packages
+(source), a directory for each supported architecture
(binary-i386, binary-m68k, etc.), and a directory
for architecture independent packages (binary-all).
-The main section contains additional directories which holds
+The main area contains additional directories which holds
the disk images and some essential pieces of documentation required
for installing the Debian distribution on a specific architecture
(disks-i386, disks-m68k, etc.).
-The binary and source directories are divided
+The binary-* and source directories are divided
further into subsections.
-The main section is what makes up the official Debian
-GNU/Linux distribution. The main section is official
-because it fully complies with all our guidelines. The other two
-sections do not, to different degrees; as such, they are not
-officially part of Debian.
+The main section of the Debian archive is what makes up the
+official Debian GNU/Linux distribution.
+The main section is official because it fully complies with
+all our guidelines. The other two sections do not, to different degrees;
+as such, they are not officially part of Debian GNU/Linux.
Every package in the main section must fully comply with the
-The packages which do not apply to the DFSG are placed in the
+Packages in the contrib section have to comply with the DFSG,
+but may fail other requirements. For instance, they may depend on
+non-free packages.
+
+Packages which do not apply to the DFSG are placed in the
non-free section. These packages are not considered as part
of the Debian distribution, though we support their use, and we
provide infrastructure (such as our bug-tracking system and mailing
lists) for non-free software packages.
-Packages in the contrib section have to comply with the DFSG,
-but may fail other requirements. For instance, they may depend on
-non-free packages.
-
The
On the other hand, a CD-ROM vendor could easily check the individual
package licenses of the packages in non-free and include as
-many on the CD-ROMs as he's allowed. (Since this varies greatly from
+many on the CD-ROMs as he's allowed to. (Since this varies greatly from
vendor to vendor, this job can't be done by the Debian developers.)
@@ -600,17 +650,21 @@ The Linux 2.0 kernel supports Intel x86, DEC Alpha, SPARC, Motorola
680x0 (like Atari, Amiga and Macintoshes), MIPS, and PowerPC. The
Linux 2.2 kernel supports even more architectures, including ARM and
UltraSPARC. Since Linux supports these platforms, Debian decided that
-it should, too. Therefore, Debian has ports underway. In fact, we
+it should, too. Therefore, Debian has ports underway; in fact, we
also have ports underway to non-Linux kernel. Aside from
i386 (our name for Intel x86), there is m68k,
alpha, powerpc, sparc, hurd-i386,
and arm, as of this writing.
-
Debian GNU/Linux 1.3 is only available as i386. Debian 2.0
shipped for i386 and m68k architectures. Debian 2.1
ships for the i386, m68k, alpha, and
-sparc architectures.
+sparc architectures. Debian 2.2 adds support for the
+powerpc and arm architectures.
+
+Information for developers or uses about the specific ports are
+available at the
+Note however that with the introduction of package pools (see the top-level
+pool/ directory), the subsections in the form of subdirectories
+will eventually cease to exist. They will be kept in the packages' `Section'
+header fields, though.
@@ -643,18 +701,16 @@ the software). In this case, the .diff.gz contains the
changes made by the Debian maintainer.
The .dsc lists all the files in the source package together
-with checksums (md5sums) and some additional info about the package
-(maintainer, version, etc.).
+with checksums (
-The directory system described in the previous chapter, are themselves
-contained within distribution directories. Every
-distribution is contained in the dists directory in the
-top-level of the Debian archive itself (the symlinks from the
-top-level directory to the distributions themselves are for backwards
-compatability and are deprecated).
+The directory system described in the previous chapter is itself
+contained within distribution directories. Each
+distribution is actually contained in the pool directory in the
+top-level of the Debian archive itself.
To summarize, the Debian archive has a root directory within an FTP
server. For instance, at the mirror site,
@@ -662,21 +718,18 @@ server. For instance, at the mirror site,
contained in
-Within that archive root, the actual distributions are contained in
-the dists directory. Here is an overview of the layout:
-
-
There is always a distribution called stable (residing in
-dists/stable) and one called unstable (residing in
+dists/stable), one called testing (residing in
+dists/testing), and one called unstable (residing in
dists/unstable). This reflects the development process of the
Debian project.
@@ -685,14 +738,26 @@ Active development is done in the unstable distribution
distribution). Every Debian developer can update his or her
packages in this distribution at any time. Thus, the contents of this
distribution change from day-to-day. Since no special effort is done
-to test this distribution, it is sometimes ``unstable.''
-
-After a period of development, the unstable distribution is
-copied in a new distribution directory, called frozen. When
-that occurs, no changes are allowed to the frozen distribution except
+to make sure everything in this distribution is working properly, it is
+sometimes ``unstable.''
+
+Packages get copied from unstable to testing if they
+satisfy certain criteria. To get into testing distribution, a
+package needs to be in the archive for two weeks and not have any release
+critical bugs. After that period, it will propagate into testing
+as soon as anything it depends on is also added. This process is automatic.
+
+After a period of development, once the release manager deems fit, the
+testing distribution is renamed to frozen. Once
+that has been done, no changes are allowed to that distribution except
bug fixes; that's why it's called ``frozen.'' After another month or
-a little longer, the frozen distribution is renamed to
-stable, overriding the old stable distribution,
+a little longer, depending on the progress, the frozen distribution
+goes into a `deep freeze', when no changes are made to it except those
+needed for the installation system. This is called a ``test cycle'', and it
+can last up to two weeks. There can be several test cycles, until the
+distribution is prepared for release, as decided by the release manager.
+At the end of the last test cycle, the frozen distribution is
+renamed to stable, overriding the old stable distribution,
which is removed at that time.
This development cycle is based on the assumption that the
@@ -708,23 +773,26 @@ muster are periodically moved as a batch into the stable distribution
and the revision level of the stable distribution is incremented
(e.g., `1.3' becomes `1.3r1', `2.0r2' becomes `2.0r3', and so forth).
-Note that development under unstable is continued during the
-``freeze'' period, since a new unstable distribution is be
-created when the older unstable is moved to frozen.
+Note that development under unstable continues during the
+``freeze'' period, since the unstable distribution remains in
+place when the testing is moved to frozen.
Another wrinkle is that when the frozen distribution is
offically released, the old stable distribution is completely removed
from the Debian archives (although they do live on at
archive-host;).
-In summary, there is always a stable and an unstable
-distribution available, and the frozen distribution shows up
-for a month or so from time to time.
+In summary, there is always a stable, a testing and an
+unstable distribution available, and a frozen distribution
+shows up for a couple of months from time to time.
The experimental distribution is a specialty distribution.
-It is not a full distribution in the same sense that `stable' and
+It is not a full distribution in the same sense as `stable' and
`unstable' are. Instead, it is meant to be a temporary staging area
for highly experimental software where there's a good chance that the
software could break your system. Users who download and install
@@ -734,7 +802,7 @@ distribution.
Developers should be very selective in the use of the
experimental distribution. Even if a package is highly
-unstable, it could well still go into unstable; just state a
+unstable, it could still go into unstable; just state a
few warnings in the description. However, if there is a chance that
the software could do grave damage to a system, it might be better to
put it into experimental.
@@ -750,11 +818,11 @@ area, so that testers can get early access.
However, using experimental as a personal staging area is not
always the best idea. You can't replace or upgrade the files in there
-on your own (
-Since the Debian has an open development model (i.e., everyone can
+Since Debian has an open development model (i.e., everyone can
participate and follow the development) even the unstable distribution
-is distributed via the Internet on the Debian FTP and HTTP server
+is distributed to the Internet through the Debian FTP and HTTP server
network. Thus, if we had called the directory which contains the
development version `unstable', then we would have to rename it to
`stable' when the version is released, which would cause all FTP
-mirrors to re-retrieve the whole distribution (which is already very
-large!).
+mirrors to re-retrieve the whole distribution (which is quite
+large).
On the other hand, if we called the distribution directories
Debian-x.y from the beginning, people would think that Debian
@@ -785,13 +853,13 @@ version. That's the reason why the first official Debian release was
1.1, and not 1.0.)
Thus, the names of the distribution directories in the archive are
-determined by their code names and not their release status (i.e.,
+determined by their code names and not their release status (e.g.,
`slink'). These names stay the same during the development period and
-after the release; symbolic links, which can be changed, are made to
+after the release; symbolic links, which can be changed easily,
indicate the currently released stable distribution. That's why the
-real distribution directories use the code names and symbolic
-links for stable, unstable, and frozen
-point to the appropriate release directories.
+real distribution directories use the code names, while symbolic
+links for stable, testing, unstable, and
+frozen point to the appropriate release directories.
If you want to create a new package for the Debian distribution, you
-should first check the
-There are a number of reasons why we ask maintainers to follow these
-steps:
+should first check the
+Assuming no one else is already working on your prospective package,
+you must then submit a short bug () against the
+pseudo package wnpp and send a copy to &email-debian-devel;
+describing your plan to create a new package, including, but not
+limiting yourself to, a description of the package, the license of the
+prospective package and the current URL where it can be downloaded
+from. You should set the subject of the bug to ``ITP: foo
+-- short description'', substituting the name of the new
+package for foo. The severity of the bug report must be
+set to wishlist. Please include a Closes:
+bug#nnnnn entry on the changelog of the new package in
+order for the bug report to be automatically closed once the new
+package is installed on the archive ().
+
+There are a number of reasons why we ask maintainers to announce their
+intentions:
The changes file is a control file with the following fields:
-
All of these fields are mandatory for a Debian upload. See the list
-of control fields in the
@@ -876,38 +940,43 @@ Notably, the Distribution field, which originates from the
+You should avoid combining `stable' with others because of potential
+problems with library dependencies (for your package and for the package
+built by the build daemons for other architecture).
+Also note that setting the distribution to `stable' means
+that the package will be placed into the proposed-updates
+directory of the Debian archive for further testing before it is actually
+included in stable. The Release Team (which can be reached at
+&email-debian-release;) will decide if your package can be included in
+stable, therefore if your changelog entry is not clear enough, you may
+want to explain them why you uploaded your package to stable by sending
+them a short explication.
The first time a version is uploaded which corresponds to a particular
-upstream version the original source tar file should be uploaded and
-included in the .changes file; subsequent times the very same
+upstream version, the original source tar file should be uploaded and
+included in the .changes file. Subsequently, this very same
tar file should be used to build the new diffs and .dsc
-files, and it need not then be uploaded.
+files, and will not need to be re-uploaded.
-By default
-If no original source is included in the upload then the original
+If no original source is included in the upload, the original
source tar-file used by
-Remember, there is statistically a 15% chance that every bug fix will
-introduce a new bug. The introduction and discovery of new bugs
-either delays release or weakens the final product. There is little
-correlation between the severity of the original bug and the severity
-of the introduced bug.
+Experience has shown that there is statistically a 15% chance that
+every bug fix will introduce a new bug. The introduction and
+discovery of new bugs either delays release or weakens the final
+product. There is little correlation between the severity of the
+original bug fixed and the severity of the bug newly introduced by the
+fix.
-Before you upload your package, you should do basic testing on it.
-Make sure you try the following activities (you'll need to have an
-older version of the Debian package around).
+Before you upload your package, you should do basic testing on it. At
+a minimum, you should try the following activities (you'll need to
+have an older version of the same Debian package around):
To upload a package, you need a personal account on
-
-Note: Do not upload packages containing software that is
-export-controlled by the United States government to master,
-or to the overseas upload queues on chiark or
+Note: Do not upload to ftp-master packages
+containing software that is export-controlled by the United States
+government, nor to the overseas upload queues on chiark or
erlangen. This prohibition covers almost all cryptographic
software, and even sometimes software that contains ``hooks'' to
cryptographic software, such as electronic mail readers that support
PGP encryption and authentication. Uploads of such software should go
-to non-us (see below). If you are not sure whether
-U.S. export controls apply to your package, post a message to
-
You may also find the Debian package
+After uploading your package, you can check how the archive maintenance
+software will process it by running
+As discussed above, export controlled software should not be uploaded
+to ftp-master. Instead, use
+The program
+You can check your upload the same way it's done on ftp-master,
+with:
+
-If you have a slow network connection to master, there are
+If you have a slow network connection to ftp-master, there are
alternatives. One is to upload files to Incoming via a
upload queue in Europe on chiark. For details connect 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 master, the
-prescription found in applies here as well.
+chiark. Since this upload queue goes to ftp-master, the
+prescription found in applies here as well.
-The program dupload supports uploads to chiark; please refer
-to the documentation that comes with the program for details.
+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
-master's Incoming, i.e., a .changes files
+ftp-master's Incoming, i.e., a .changes files
along with the other files mentioned in the .changes. The
queue daemon also checks that the .changes is correctly
PGP-signed by a Debian developer, so that no bogus files can find
-their way to master via the queue. Please also make sure that
+their way to ftp-master via this queue. Please also make sure that
the Maintainer field in the .changes contains
your e-mail address. The address found there is used for all
-replies, just as on master.
+replies, just as on ftp-master.
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 some
-mail reply from the queue daemon what happened to your
-upload. Hopefully it should have been moved to master, but in
+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.
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 master, the
-prescription found in applies here as well.
+erlangen. Since this upload queue goes to ftp-master, the
+prescription found in applies here as well.
-The program
-To upload a package to the non-us server you just have to
-transfer the files via anonymous ftp to
+An upload queue is available in Japan: just upload the files via
+anonymous FTP to
-When a package is uploaded an announcement should be posted to one of
-the ``debian-changes'' lists. The announcement should give the
-(source) package name and version number, and a very short summary of
-the changes, in the Subject field, and should contain the
-PGP-signed .changes file. Some additional explanatory text
-may be added before the start of the .changes file.
+When a package is uploaded, an announcement should be posted to one of
+the ``debian-changes'' lists. This is now done automatically by the archive
+maintenance software when it runs (usually once a day). You just need to use
+a recent
If a package is released with the Distribution: set to
-`stable', the announcement is sent to
-
On occasion, it is necessary to upload a package to both the
stable and unstable distributions; this is done by
putting both distributions in the Distribution: line. In
-such a case the upload announcement should go to both of the above
+such a case the upload announcement will go to both of the above
mailing lists.
-The
The Debian archive maintainers are responsible for handling package
uploads. For the most part, uploads are automatically handled on a
-daily basis by an archive maintenance tool called
-
-In any case, you will receive notification indicating that the package
-has been uploaded via email. Please examine this notification
+In any case, you will receive email notification indicating that the
+package has been uploaded. Please examine this notification
carefully. You may notice that the package didn't go into the section
you thought you set it to go into. Read on for why.
@@ -1130,13 +1221,12 @@ The archive maintainers keep track of the canonical sections and
priorities for packages in the override file. Sometimes the
override file needs correcting. Simply changing the
package's
For more information about override files, see
-A source NMU is a upload of a package by a developer who is not the
+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 NMU is a recompilation and upload of a binary package for a
new architecture. As such, it is usually part of a porting effort. A
-binary NMU is non-maintainer uploaded binary version of a package
+binary NMU is a non-maintainer uploaded binary version of a package
(often for another architecture), 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
@@ -1209,7 +1299,7 @@ slightly different rules than non-porters, due to their unique
circumstances (see ).
Only critical changes or security bug fixes make it into stable. When
-a security bug is detected a fixed package should be uploaded as soon
+a security bug is detected, a fixed package should be uploaded as soon
as possible. In this case, the Debian Security Managers should get in
contact with the package maintainer to make sure a fixed package is
uploaded within a reasonable time (less than 48 hours). If the package
@@ -1218,7 +1308,7 @@ cannot be reached in time, the Security Manager may upload a fixed
package (i.e., do a source NMU).
During the release freeze (see ), NMUs which
-fix important or higher severity bugs are encouraged and accepted.
+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
@@ -1384,7 +1474,7 @@ fact, all the prescriptions from apply, including
the need to announce the NMU to the proper lists.
Make sure you do not change the value of the maintainer in
-the
-Porting is the act of building Debian packages for architectures which
+Porting is the act of building Debian packages for architectures that
is 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 one i386 binary package, there has to be a
-recompile for each architecture, which is around five more builds.
+For instance, for a single i386 binary package, there must be a
+recompile for each architecture, which is amounts to five more builds.
Porters have a difficult and unique task, since they are required to
deal with a large volume of packages. Ideally, every source package
-should build right out of the box; unfortunately, this is often not
+should build right out of the box. Unfortunately, this is often not
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 more difficult.
@@ -1429,10 +1519,8 @@ of things you should check or be aware of.
+Sometimes you need to recompile a package against other packages
+which have been updated, such as libraries. You do have to bump the
+version number in this case, so that the upgrade system can function
+properly. Even so, these are considered binary-only NMUs -- there is
+no need in this case for all architectures to recompile. You should
+set the version number as in the case of NMU versioning, but add a
+``.0.'' before the the NMU version. For instance, a recompile-only
+NMU of the source package ``foo_1.3-1'' would be numbered
+``foo_1.3-1.0.1''.
+
The way to invoke
Secondly, porters doing source NMUs should make sure that the bug they
-submit to the BTS should be of severity `important' or greater. This
+submit to the BTS should be of severity `serious' or greater. This
ensures that a single source package can be used to compile every
supported Debian architecture by release time. It is very important
that we have one version of the binary and source package for all
@@ -1560,7 +1658,14 @@ cannot yet be autobuilt) and work on it.
most porting efforts are either using it currently or planning to use
it in the near future. It collects a number of as yet unpackaged
components which are currently very useful and in use continually,
-such as
+Some of the data produced by
We are very excited about this system, since it potentially has so
many uses. Independent development groups can use the system for
@@ -1593,25 +1698,32 @@ cases.
-Sometimes a package will change either its section or its subsection.
-For instance, a package from the `non-free' section might be GPL'd in
-a later version; in this case you should consider moving it to `main'
-or `contrib' (see the
-In this case, it is sufficient to edit the package control information
-normally and re-upload the package (see the
+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
+
+
-
+&control-file-fields;
-