[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ A ] [ next ]

Debian Developer's Reference
Chapter 4 - Resources for Debian Developers


In this chapter you will find a very brief road map of the Debian mailing lists, the Debian machines which may be available to you as a developer, and all the other resources that are available to help you in your maintainer work.


4.1 Mailing lists

The mailing list server is at lists.debian.org.

Online archives of mailing lists are available at http://lists.debian.org/.


4.1.1 Core development mailing lists

The core Debian mailing lists that developers should use are:

There are other mailing lists available for a variety of special topics; see http://www.debian.org/MailingLists/subscribe for a list.


4.1.2 Subscribing and unsubscribing

To subscribe to or unsubscribe from any of the Debian mailing lists, email debian-foo-REQUEST@lists.debian.org, 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.

If you prefer to use a web page to subscribe to multiple mailing lists, there's one at http://www.debian.org/MailingLists/subscribe.

You can download the current list of mailing lists and basic usage instructions from http://ftp.debian.org/debian/doc/mailing-lists.txt or install the doc-debian package and have it locally in /usr/share/doc/debian/mailing-lists.txt.


4.1.3 Basic rules for use

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.

Cross-posting (sending the same message to multiple lists) is discouraged. 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.

Please read the code of conduct for more information.


4.1.4 Special lists

debian-private@lists.debian.org is a special mailing list for private discussions amongst Debian developers. It is meant to be used for posts which for whatever reason should not be published publicly. As such, it is a low volume list, and users are urged not to use debian-private@lists.debian.org unless it is really necessary. Moreover, do not forward email from that list to anyone. Archives of this list are not available on the web for obvious reasons, but you can see them using your shell account on lists.debian.org and looking in the ~debian/archive/debian-private directory.

debian-email@lists.debian.org 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.


4.2 IRC channels

Several IRC channels are dedicated to Debian's development. They are mainly hosted on the freenode network (previously known as Open Projects Network). The irc.debian.org DNS entry is an alias to irc.freenode.net.

The main channel for Debian in general is #debian. This is a large, general-purpose channel where users can find recent news in the topic and served by bots. #debian is for English speakers; there are also #debian.de, #debian-fr, #debian-br and other similarly named channels for speakers of other languages.

The main channel for Debian development is #debian-devel. It is a very active channel since usually over 150 people are always logged in. It's a channel for people who work on Debian, it's not a support channel (there's #debian for that). It is however open to anyone who wants to lurk (and learn). Its topic is commonly full of interesting information for developers.

Since #debian-devel it's an open channel, you should not speak there of issues that are discussed in debian-private@lists.debian.org. There's another channel for this purpose, it's called #debian-private and it's protected by a key. This key is available in the archives of debian-private in master.debian.org:~debian/archive/debian-private/, just zgrep for #debian-private in all the files.

There are other additional channels dedicated to specific subjects. #debian-bugs is used for coordinating bug squash parties. #debian-boot is used to coordinate the work on the boot floppies (i.e., the installer). #debian-doc is occasionally used to talk about documentation, like the document you are reading. Other channels are dedicated to an architecture or a set of packages: #debian-bsd, #debian-kde, #debian-jr, #debian-edu, #debian-sf (SourceForge package), #debian-oo (OpenOffice package) ...

Some non-English developers' channels exist as well, for example #debian-devel-fr for French speaking people interested in Debian's development.

Channels dedicated to Debian also exist on other IRC networks, notably on the Open and free technology community (OFTC) IRC network.


4.3 Documentation

This document contains a lot of information very useful to Debian developers, but it can not contain everything. Most of the other interesting documents are linked from The Developers' Corner. Take the time to browse all the links, you will learn many more things.


4.4 Debian machines

Debian has several computers working as servers, most of which serve critical functions in the Debian project. Most of the machines are used for porting activities, and they all have a permanent connection to the Internet.

Most of the machines are available for individual developers to use, as long as the developers follow the rules set forth in the Debian Machine Usage Policies.

Generally speaking, you can use these machines for Debian-related purposes as you see fit. Please be kind to system administrators, and do not use up tons and tons of disk space, network bandwidth, or CPU without first getting the approval of the system administrators. Usually these machines are run by volunteers.

Please take care to protect your Debian passwords and SSH keys installed on Debian machines. Avoid login or upload methods which send passwords over the Internet in the clear, such as telnet, FTP, POP etc.

Please do not put any material that doesn't relate to Debian on the Debian servers, unless you have prior permission.

The current list of Debian machines is available at http://db.debian.org/machines.cgi. That web page contains machine names, contact information, information about who can log in, SSH keys etc.

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 debian-admin@lists.debian.org.

If you have a problem with a certain service, not related to the system 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 Bug reporting, Section 7.1 for information on how to submit bugs.


4.4.1 The bugs server

bugs.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 debian-devel@lists.debian.org before implementing anything, however, to reduce unnecessary duplication of effort or wasted processing time.

All Debian developers have accounts on bugs.debian.org.


4.4.2 The ftp-master server

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 Uploading a package, Section 5.6.

Problems with the Debian FTP archive generally need to be reported as bugs against the ftp.debian.org pseudo-package or an email to ftpmaster@debian.org, but also see the procedures in Moving, removing, renaming, adopting, and orphaning packages, Section 5.9.


4.4.3 The non-US server

The non-US server, non-us.debian.org, holds the canonical copy of the non-US part of the Debian archive. If you need to upload a package into one of the non-US sections, upload it to this server; see Uploading to non-US, Section 5.6.2.

Problems with the non-US package archive should generally be submitted as bugs against the nonus.debian.org pseudo-package (notice the lack of hyphen between "non" and "us" in the pseudo-package name — that's for backwards compatibility). Remember to check whether or not someone else has already reported the problem on the Bug Tracking System.


4.4.4 The www-master server

The main web server is www-master.debian.org. It holds the official web pages, the face of Debian for most newbies.

If you find a problem with the Debian web server, you should generally submit a bug against the pseudo-package, www.debian.org. Remember to check whether or not someone else has already reported the problem on the Bug Tracking System.


4.4.5 The people web server

people.debian.org is the server used for developers' own web pages about anything related to Debian.

If you have some Debian-specific information which you want to serve on the web, you can do this by putting material in the public_html directory under your home directory on people.debian.org. This will be accessible at the URL http://people.debian.org/~your-user-id/.

You should only use this particular location because it will be backed up, whereas on other hosts it won't.

Usually the only reason to use a different host is when you need to publish materials subject to the U.S. export restrictions, in which case you can use one of the other servers located outside the United States, such as the aforementioned non-us.debian.org.

Send mail to debian-devel@lists.debian.org if you have any questions.


4.4.6 The CVS server

Our CVS server is located on cvs.debian.org.

If you need to use a publicly 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 ssh. Also, the CVS area can be accessed read-only via the Web at http://cvs.debian.org/.

To request a CVS area, send a request via email to debian-admin@debian.org. Include the name of the requested CVS area, the Debian account that should own the CVS root area, and why you need it.


4.5 The Developers Database

The Developers Database, at https://db.debian.org/, is an LDAP directory for managing Debian developer attributes. You can use this resource to search the list of Debian developers. Part of this information is also available through the finger service on Debian servers, try finger yourlogin@db.debian.org to see what it reports.

Developers can log into the database to change various information about themselves, such as:

Most of the information is not accessible to the public, naturally. For more information please read the online documentation that you can find at http://db.debian.org/doc-general.html.

One can also submit their SSH keys to be used for authorization on the official Debian machines, and even add new *.debian.net DNS entries. Those features are documented at http://db.debian.org/doc-mail.html.


4.6 The Debian archive

The Debian GNU/Linux distribution consists of a lot of packages (.deb's, currently around 9000) and a few additional files (such documentation and installation disk images).

Here is an example directory tree of a complete Debian archive:

     dists/stable/main/
     dists/stable/main/binary-i386/
     dists/stable/main/binary-m68k/
     dists/stable/main/binary-alpha/
          ...
     dists/stable/main/source/
          ...
     dists/stable/main/disks-i386/
     dists/stable/main/disks-m68k/
     dists/stable/main/disks-alpha/
          ...
     
     dists/stable/contrib/
     dists/stable/contrib/binary-i386/
     dists/stable/contrib/binary-m68k/
     dists/stable/contrib/binary-alpha/
          ...
     dists/stable/contrib/source/
     
     dists/stable/non-free/
     dists/stable/non-free/binary-i386/
     dists/stable/non-free/binary-m68k/
     dists/stable/non-free/binary-alpha/
          ...
     dists/stable/non-free/source/
     
     dists/testing/
     dists/testing/main/
          ...
     dists/testing/contrib/
          ...
     dists/testing/non-free/
          ...
     
     dists/unstable
     dists/unstable/main/
          ...
     dists/unstable/contrib/
          ...
     dists/unstable/non-free/
          ...
     
     pool/
     pool/main/a/
     pool/main/a/apt/
          ...
     pool/main/b/
     pool/main/b/bash/
          ...
     pool/main/liba/
     pool/main/liba/libalias-perl/
          ...
     pool/main/m/
     pool/main/m/mailx/
          ...
     pool/non-free/n/
     pool/non-free/n/netscape/
          ...

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. The Packages and Sources files in the distribution subdirectories can reference files in the pool/ directory. The directory tree below each of the distributions is arranged in an identical manner. What we describe below for stable is equally applicable to the unstable and testing distributions.

dists/stable contains three directories, namely main, contrib, and non-free.

In each of the areas, there is a directory for the source packages (source) and a directory for each supported architecture (binary-i386, binary-m68k, etc.).

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.).


4.6.1 Sections

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 Debian Free Software Guidelines (DFSG) and with all other policy requirements as described in the Debian Policy Manual. The DFSG is our definition of “free software.” Check out the Debian Policy Manual for details.

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 conform 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.

The Debian Policy Manual contains a more exact definition of the three sections. The above discussion is just an introduction.

The separation of the three sections at the top-level of the archive is important for all people who want to distribute Debian, either via FTP servers on the Internet or on CD-ROMs: by distributing only the main and contrib sections, one can avoid any legal risks. Some packages in the non-free section do not allow commercial distribution, for example.

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 to. (Since this varies greatly from vendor to vendor, this job can't be done by the Debian developers.)

Note also that the term "section" is also used to refer to categories which simplify the organization and browsing of available packages, e.g. admin, net, utils etc. Once upon a time, these sections (subsections, rather) existed in the form of subdirectories within the Debian archive. Nowadays, these exist only in the "Section" header fields of packages.


4.6.2 Architectures

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 more and more popular, the kernel was ported to other architectures, too.

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 also have ports underway to non-Linux kernel. Aside from i386 (our name for Intel x86), there is m68k, alpha, powerpc, sparc, hurd-i386, arm, ia64, hppa, s390, mips, mipsel and sh 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. Debian 2.2 added support for the powerpc and arm architectures. Debian 3.0 adds support of five new architectures: ia64, hppa, s390, mips and mipsel.

Information for developers or uses about the specific ports are available at the Debian Ports web pages.


4.6.3 Packages

There are two types of Debian packages, namely source and binary packages.

Source packages consist of either two or three files: a .dsc file, and either a .tar.gz file or both an .orig.tar.gz and a .diff.gz file.

If a package is developed specially for Debian and is not distributed outside of Debian, there is just one .tar.gz file which contains the sources of the program. If a package is distributed elsewhere too, the .orig.tar.gz file stores the so-called upstream source code, that is the source code that's distributed from the upstream maintainer (often the author of the software). In this case, the .diff.gz contains the changes made by the Debian maintainer.

The .dsc file lists all the files in the source package together with checksums (md5sums) and some additional info about the package (maintainer, version, etc.).


4.6.4 Distributions

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, ftp.us.debian.org, the Debian archive itself is contained in /debian, which is a common location (another is /pub/debian).

A distribution is comprised of Debian source and binary packages, and the respective Sources and Packages index files, containing the header information from all those packages. The former are kept in the pool/ directory, while the latter are kept in the dists/ directory of the archive (for backwards compatibility).


4.6.4.1 Stable, testing, and unstable

There are always distributions called stable (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.

Active development is done in the unstable distribution (that's why this distribution is sometimes called the development distribution). Every Debian developer can update his or her packages in this distribution at any time. Thus, the contents of this 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.

More information about the testing distribution, Section 4.6.4.2 is generated automatically by taking packages from unstable if they satisfy certain criteria. Those criteria should ensure a good quality for packages within testing. The update to testing is launched each day after the new packages have been installed.

After a period of development, once the release manager deems fit, the testing distribution is frozen, meaning that the policies which control how packages move from unstable to testing are tightened. Packages which are too buggy are removed. No changes are allowed into testing except for bug fixes. After some time has elapsed, depending on progress, the testing 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 testing distribution is renamed to stable, overriding the old stable distribution, which is removed at that time (although it can be found at archive.debian.org).

This development cycle is based on the assumption that the unstable distribution becomes stable after passing a period of being in testing. Even once a distribution is considered stable, a few bugs inevitably remain — that's why the stable distribution is updated every now and then. However, these updates are tested very carefully and have to be introduced into the archive individually to reduce the risk of introducing new bugs. You can find proposed additions to stable in the proposed-updates directory. Those packages in proposed-updates that pass muster are periodically moved as a batch into the stable distribution and the revision level of the stable distribution is incremented (e.g., ‘3.0’ becomes ‘3.0r1’, ‘2.2r4’ becomes ‘2.2r5’, and so forth).

Note that development under unstable continues during the freeze period, since the unstable distribution remains in place in parallel with testing.


4.6.4.2 More information about the testing distribution

The scripts that update the testing distribution are run each day after the installation of the updated packages. They generate the Packages files for the testing distribution, but they do so in an intelligent manner trying to avoid any inconsistency and trying to use only non-buggy packages.

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 web page of the testing distribution, or use the program grep-excuses which is in the devscripts package. This utility can easily be used in a crontab(5) to keep one informed of the progression of their packages into testing.

The update_excuses file does not always give the precise reason why the package is refused, one may have to find it on their own by looking what would break with the inclusion of the package. The testing web page gives some more information about the usual problems which may be causing such troubles.

Sometimes, some packages never enter testing because the set of inter-relationship is too complicated and can not 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 testing web page for more information. It also includes answers to some of the frequently asked questions.


4.6.4.3 Experimental

The experimental distribution is a special distribution. 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, or software that's just too unstable even for the unstable distribution (but there is a reason to package it nevertheless). Users who download and install packages from experimental are expected to have been duly warned. In short, all bets are off for the experimental distribution.

These are the sources.list(5) lines for experimental:

     deb http://ftp.xy.debian.org/debian/ ../project/experimental main
     deb-src http://ftp.xy.debian.org/debian/ ../project/experimental main

If there is a chance that the software could do grave damage to a system, it is likely to be better to put it into experimental. For instance, an experimental compressed file system should probably go into experimental.

Whenever there is a new upstream version of a package that introduces new features but breaks a lot of old ones, it should either not be uploaded, or be uploaded to experimental. A new, beta, version of some software which uses completely different configuration can go into experimental, at the maintainer's discretion. If you are working on an incompatible or complex upgrade situation, you can also use experimental as a staging area, so that testers can get early access.

Some experimental software can still go into unstable, with a few warnings in the description, but that isn't recommended because packages from unstable are expected to propagate to testing and thus to stable. You should not be afraid to use experimental since it does not cause any pain to the ftpmasters, the experimental packages are automatically removed once you upload the package in unstable with a higher version number.

New software which isn't likely to damage your system can go directly into unstable.

An alternative to experimental is to use your personal web space on people.debian.org.


4.6.5 Release code names

Every released Debian distribution has a code name: Debian 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'; and Debian 3.0, `woody'. 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. As well as the usual contents of a Debian distribution, `sid' contains packages for architectures which are not yet officially supported or released by Debian. These architectures are planned to be integrated into the mainstream distribution at some future date.

Since Debian has an open development model (i.e., everyone can participate and follow the development) even the `unstable' and `testing' distributions are distributed to the Internet through the Debian FTP and HTTP server network. Thus, if we had called the directory which contains the release candidate version `testing', 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 quite large).

On the other hand, if we called the distribution directories Debian-x.y from the beginning, people would think that Debian release x.y is available. (This happened in the past, where a CD-ROM vendor built a Debian 1.0 CD-ROM based on a pre-1.0 development 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 (e.g., `slink'). These names stay the same during the development period and 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, while symbolic links for stable, testing, and unstable point to the appropriate release directories.


4.7 Debian mirrors

The various download archives and the web site have several mirrors available in order to relieve our canonical servers from heavy load. In fact, some of the canonical servers aren't public, and instead a first tier of mirrors balances the load. That way, users always access the mirrors and get used to using them, which allows Debian to better spread its bandwidth requirements over several servers and networks, and basically makes users avoid hammering on one primary location. Note that the first tier of mirrors is as up-to-date as it can be since they update when triggered from the internal sites (we call this "push mirroring").

All the information on Debian mirrors, including a list of the available public FTP/HTTP servers, can be found at http://www.debian.org/mirror/. This useful page also includes information and tools which can be helpful if you are interested in setting up your own mirror, either for internal or public access.

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.


4.8 The Incoming system

The Incoming system is responsible of collecting updated packages and installing them in the Debian archive. It consists of a set of directories and scripts that are installed both on ftp-master.debian.org and non-us.debian.org.

Packages are uploaded by all the maintainers into a directory called unchecked. This directory is scanned every 15 minutes by the katie script, which verifies the integrity of the uploaded packages and the cryptographic signatures. If the package is considered ready to be installed, it is moved into the accepted directory. If this is the first upload of the package, it is moved in the new directory, where it waits for an approval of the ftpmasters. If the package contains files to be installed "by-hand" it is moved in the byhand directory, where it waits for a manual installation by the ftpmasters. Otherwise, if any error has been detected, the package is refused and is moved in the reject directory.

Once the package is accepted the system sends a confirmation mail to the maintainer, closes all the bugs marked as fixed by the upload and the auto-builders may start recompiling it. The package is now publicly accessible at http://incoming.debian.org/ (there is no such URL for packages in the non-US archive) until it is really installed in the Debian archive. This happens only once a day, 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 Packages and Sources index files for example) have been made, a special script is called to ask all the primary mirrors to update themselves.

The archive maintenance software will also send the OpenPGP/GnuPG signed .changes file that you uploaded to the appropriate mailing lists. If a package is released with the Distribution: set to `stable', the announcement is sent to debian-changes@lists.debian.org. If a package is released with Distribution: set to `unstable' or `experimental', the announcement will be posted to debian-devel-changes@lists.debian.org instead.

All Debian developers have write access to the unchecked directory in order to upload their packages, they also have that access to the reject directory in order to remove their bad uploads or to move some files back in the unchecked directory. But all the other directories are only writable by the ftpmasters, that is why you can not remove an upload once it has been accepted.


4.8.1 Delayed incoming

The unchecked directory has a special DELAYED subdirectory. It is itself subdivided in nine directories called 1-day to 9-day. Packages which are uploaded in one of those directories will be moved in the real unchecked directory after the corresponding number of days. This is done by a script that is run each day and which moves the packages between the directories. Those which are in "1-day" are installed in unchecked while the others are moved in the adjacent directory (for example, a package in 5-day will be moved in 4-day). This feature is particularly useful for people who are doing non-maintainer uploads. Instead of waiting before uploading a NMU, it is uploaded as soon as it is ready but in one of those DELAYED/x-day directories. That leaves the corresponding number of days for the maintainer to react and upload another fix themselves if they are not completely satisfied with the NMU. Alternatively they can remove the NMU.

The use of that delayed feature can be simplified with a bit of integration with your upload tool. For instance, if you use dupload (see dupload, Section A.5.1), you can add this snippet to your configuration file:

     $delay = ($ENV{DELAY} || 7);
     $cfg{'delayed'} = {
              fqdn => "ftp-master.debian.org",
              login => "yourdebianlogin",
              incoming => "/org/ftp.debian.org/incoming/DELAYED/$delay-day/",
              dinstall_runs => 1,
              method => "scpb"
     };

Once you've made that change, dupload can be used to easily upload a package in one of the delayed directories:

     DELAY=5 dupload --to delayed <changes-file>

4.9 Package information


4.9.1 On the web

Each package has several dedicated web pages. http://packages.debian.org/package-name displays each version of the package available in the various distributions. Each version links to a page which provides information, including the package description, the dependencies and package download links.

The bug tracking system track bugs for each package. You can view the bugs of a given package at the URL http://bugs.debian.org/package-name.


4.9.2 The madison utility

madison is a command-line utility that is available on both ftp-master.debian.org and non-us.debian.org. It uses a single argument corresponding to a package name. In result it displays which version of the package is available for each architecture and distribution combination. An example will explain it better.

     $ madison libdbd-mysql-perl
     libdbd-mysql-perl |   1.2202-4 |        stable | source, alpha, arm, i386, m68k, powerpc, sparc
     libdbd-mysql-perl |   1.2216-2 |       testing | source, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
     libdbd-mysql-perl | 1.2216-2.0.1 |       testing | alpha
     libdbd-mysql-perl |   1.2219-1 |      unstable | source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc

In this example, you can see that the version in unstable differs from the version in testing and that there has been a binary-only NMU of the package for the alpha architecture. Each time the package has been recompiled on most of the architectures.


4.10 The Package Tracking System

The Package Tracking System (PTS) is basically a tool to track by mail the activity of a source package. You just have to subscribe to a source package to start getting the mails related to it. You get the same mails as the maintainer. Each mail sent through the PTS is classified and associated to one of the keyword listed below. This will let you select the mails that you want to receive.

By default you will get:

bts
All the bug reports and following discussions.
bts-control
The control mails notifying a status change in one of the bugs.
upload-source
The confirmation mail from katie when an uploaded source package is accepted.
katie-other
Other warning and error mails from katie (like the override disparity for the section or priority field).
default
Any non-automatic mail sent to the PTS by people who wanted to contact the subscribers of the package. This can be done by sending mail to srcpackage@packages.qa.debian.org. In order to prevent spam, mails sent to these addresses must contain the header "X-PTS-Approved" with a non-empty string.
summary
In the future, you may receive regular summary mails to keep you informed of the package's status (bug statistics, porting overview, progression in testing, ...).

You can also decide to receive some more information:

upload-binary
The confirmation mail from katie when an uploaded binary package is accepted (to check that your package is recompiled for all architectures).
cvs
CVS commits if the maintainer has setup a system to forward commit notification to the PTS.
ddtp
Translations of descriptions or debconf templates submitted to the Debian Description Translation Project.

4.10.1 The PTS email interface

You can control your subscription(s) to the PTS by sending various commands to pts@qa.debian.org.

subscribe <srcpackage> [<email>]
Subscribes email to communications related to the source package srcpackage. Sender address is used if the second argument is not present. If srcpackage is not a valid source package, you'll get a warning. However if it's a valid binary package, the PTS will subscribe you to the corresponding source package.
unsubscribe <srcpackage> [<email>]
Removes a previous subscription to the source package srcpackage using the specified email address or the sender address if the second argument is left out.
which [<email>]
Lists all subscriptions for the sender or the email address optionally specified.
keyword [<email>]
Tells you the keywords that you are accepting. Each mail sent through the Package Tracking System is associated to a keyword and you receive only the mails associated to keywords that you are accepting. Here is the list of available keywords:
keyword <srcpackage> [<email>]
Same as previous item but for the given source package since you may select a different set of keywords for each source package.
keyword [<email>] {+|-|=} <list of keywords>
Accept (+) or refuse (-) mails associated to the given keyword(s). Define the list (=) of accepted keywords.
keyword <srcpackage> [<email>] {+|-|=} <list of keywords>
Same as previous item but overrides the keywords list for the indicated source package.
quit | thanks | --
Stops processing commands. All following lines are ignored by the bot.

4.10.2 Filtering PTS mails

Once you are subscribed to a package, you will get the mails sent to srcpackage@packages.qa.debian.org. Those mails have special headers appended to let you filter them in a special mailbox with procmail. The added headers are X-Loop, X-PTS-Package, X-PTS-Keyword and X-Unsubscribe.

Here is an example of added headers for a source upload notification on the dpkg package:

     X-Loop: dpkg@packages.qa.debian.org
     X-PTS-Package: dpkg
     X-PTS-Keyword: upload-source
     X-Unsubscribe: echo 'unsubscribe dpkg' | mail pts@qa.debian.org

4.10.3 Forwarding CVS commits in the PTS

If you use a publicly accessible CVS repository for maintaining your Debian package you may want to forward the commit notification to the PTS so that the subscribers (possible co-maintainers) can closely follow the package's evolution.

It's very easy to setup. Once your CVS repository generates commit notifications, you just have to make sure it sends a copy of those mails to srcpackage_cvs@packages.qa.debian.org. Only people who accepts the cvs keyword will receive the notifications.


4.10.4 The PTS web interface

The PTS has been extended with a web interface that puts together many information about each source package. It features many useful links (BTS, QA stats, contact information, DDTP translation status, buildd logs) and gathers many more information from various places (30 latest changelog entries, testing status, ...). It's a very useful tool if you want to know what's going on with a specific source package. Furthermore there's a form that let you easily subscribe to the mail service offered by the PTS.

You can jump directly to the web page concerning a specific source package with an url like http://packages.qa.debian.org/srcpackage. Otherwise you can go through the main page.

This web interface has been designed like a portal for the development of packages: you can add custom content on the pages of your packages. You can add "static information" (news item that are meant to stay available indefinitely) and news items in the "latest news" section.

Static news can be used to indicate:

Usual news item may be used to announce that:

Both kind of news are generated in a similar manner: you just have to send a mail either to pts-static-news@qa.debian.org or to pts-news@qa.debian.org. The mail should indicate which package is concerned by the news by giving the name of the source package in a X-PTS-Package mail header or in a Package pseudo-header (like the BTS reports). If an URL is available in the X-PTS-Url mail header or in the Url pseudo-header, then the result is a link to that URL instead of a complete news item.

Some examples of valid mails used to generate news item in the PTS are following. The first one adds a link to the cvsweb interface of debian-cd in the "Static information" section.

     From: Raphael Hertzog <hertzog@debian.org>
     To: pts-static-news@qa.debian.org
     Subject: Browse debian-cd CVS repository with cvsweb
     
     Package: debian-cd
     Url: http://cvs.debian.org/debian-cd/

The second one is an announce sent to a mailing list which is also sent to the PTS so that it is published on the PTS web page of the package. Note the use of the BCC field to avoid answers sent to the PTS by mistake ...

     From: Raphael Hertzog <hertzog@debian.org>
     To: debian-gtk-gnome@lists.debian.org
     Bcc: pts-news@qa.debian.org
     Subject: Galeon 2.0 backported for woody
     X-PTS-Package: galeon
     
     Hello gnomers !
     
     I'm glad to announce that galeon has been backported for woody. You'll find
     everything here:
     ...

Think twice before adding a news to the PTS because you won't be able to remove it later and you wan't be able to edit it either. The only thing that you can do is send a second news that will deprecate the information contained in the first news.


4.11 Developer's packages overview

A QA (quality assurance) web portal is available at http://qa.debian.org/developer.php which displays a table listing all the packages of a single developer (including those where the party is listed as a co-maintainer). The table gives a good summary about the developer's packages: number of bugs by severity, list of available versions in each distribution, testing status and much more including links to any other useful information.

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.


[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ A ] [ next ]

Debian Developer's Reference

ver. 3.3.3, 16 June, 2003

Developer's Reference Team developers-reference@packages.debian.org
Adam Di Carlo, editor
Raphaël Hertzog
Christian Schwarz
Ian Jackson