[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ A ] [ next ]
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.
Much of the conversation between Debian developers (and users) is managed
through a wide array of mailing lists we host at lists.debian.org. To find
out more on how to subscribe or unsubscribe, how to post and how not to post,
where to find old posts and how to search them, how to contact the list
maintainers and see various other information about the mailing lists, please
read http://www.debian.org/MailingLists/.
This section will only cover aspects of mailing lists that are of particular
interest to developers.
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. The Debian Community
Guidelines are also worth reading.
The core Debian mailing lists that developers should use are:
[email protected],
used to announce important things to developers. All developers are expected
to be subscribed to this list.
[email protected],
used to discuss various development related technical issues.
[email protected],
where the Debian Policy is discussed and voted on.
[email protected],
used to discuss various non-technical issues related to the project.
There are other mailing lists available for a variety of special topics; see
http://lists.debian.org/
for a list.
[email protected]
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 [email protected]
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.
[email protected]
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.
Before requesting a mailing list that relates to the development of a package (or a small group of related packages), please consider if using an alias (via a .forward-aliasname file on master.debian.org, which translates into a reasonably nice [email protected] address) or a self-managed mailing list on Alioth is more appropriate.
If you decide that a regular mailing list on lists.debian.org is really what
you want, go ahead and fill in a request, following the
HOWTO.
Several IRC channels are dedicated to Debian's development. They are mainly
hosted on the Open and free
technology community (OFTC) network. The
irc.debian.org DNS entry is an alias to irc.oftc.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 is an open channel, you should not speak there of
issues that are discussed in [email protected].
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 squashing parties. #debian-boot is used to coordinate the work on the debian-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-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
freenode IRC network, which
was pointed at by the irc.debian.org alias until 4th June 2006.
To get a cloak on freenode, you send Jörg Jaspert <[email protected]>
a signed mail where you tell what your nick is. Put "cloak"
somewhere in the Subject: header. The nick should be registered: Nick Setup Page. The
mail needs to be signed by a key in the Debian keyring. Please see Freenodes
documentation for more information about cloaks.
This document contains a lot of information which is useful to Debian
developers, but it cannot 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.
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.
Some 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, you can check the
list of open issues in the DSA queue of our request tracker at https://rt.debian.org/ (you can login
with user "guest" and password "readonly"). To report a
new problem, simply send a mail to [email protected] and make sure
to put the string "Debian RT" somewhere in the subject.
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.
Some of the core servers are restricted, but the information from there is mirrored to another server.
bugs.debian.org is the canonical location for the Bug Tracking 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 protected]
before implementing anything, however, to reduce unnecessary duplication of
effort or wasted processing time.
The ftp-master.debian.org server holds the canonical copy of the Debian archive. Generally, package uploads go to this server; see Uploading a package, Section 5.6.
It is restricted; a mirror is available on merkel.
Problems with the Debian FTP archive generally need to be reported as bugs
against the ftp.debian.org pseudo-package or an email to [email protected], but also
see the procedures in Moving,
removing, renaming, adopting, and orphaning packages, Section 5.9.
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 to the Bug Tracking System.
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.
Send mail to [email protected]
if you have any questions.
If you need to use a Version Control System for any of your Debian work, you
can use one the existing repositories hosted on Alioth or you can request a new
project and ask for the VCS repository of your choice. Alioth supports CVS
(alioth.debian.org), Subversion (svn.debian.org), Arch (tla/baz, both on
arch.debian.org), Bazaar (bzr.debian.org), Mercurial (hg.debian.org) and Git
(git.debian.org). Checkout http://wiki.debian.org/Alioth/PackagingProject
if you plan to maintain packages in a VCS repository. See Debian's GForge installation: Alioth, Section 4.12 for
information on the services provided by Alioth.
Historically, Debian first used cvs.debian.org to host CVS repositories. But that service is deprecated in favor of Alioth. Only a few projects are still using it.
On some machines, there are chroots to different distributions available. You can use them like this:
vore% dchroot unstable
Executing shell in chroot: /org/vore.debian.org/chroots/user/unstable
In all chroots, the normal user home directories are available. You can find out which chroots are available via http://db.debian.org/machines.cgi.
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
[email protected] to see what it reports.
Developers can log into the
database to change various information about themselves, such as:
forwarding address for your debian.org email
subscription to debian-private
whether you are on vacation
personal information such as your address, country, the latitude and longitude
of the place where you live for use in the world map of Debian
developers, phone and fax numbers, IRC nickname and web page
password and preferred shell on Debian Project machines
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.
Developers 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.
The Debian GNU/Linux distribution consists of a lot of packages
(.deb's, currently around 9000) and a few additional files (such
as 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 hold 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 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 it's allowed to. (Since this varies greatly from vendor to vendor, this job can't be done by the Debian developers.)
Note 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.
In the first days, the Linux kernel was only available for Intel i386 (or greater) platforms, and so was Debian. But as Linux became more and more popular, the kernel was ported to other architectures, too.
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 kernels. 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 added support of five new architectures: ia64, hppa, s390, mips and mipsel.
Information for developers and users about the specific ports are available at
the Debian Ports web
pages.
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 by 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.).
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 comprises 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).
There are always distributions called stable (residing in
dists/stable), testing (residing in
dists/testing), and 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 change from day to day. Since no special effort is made to make sure everything in this distribution is working properly, it is sometimes literally unstable.
The "testing" distribution 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. See The testing distribution, Section 5.13.
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 is frozen even further. Details of the handling of the testing distribution are published by the Release Team on debian-devel-announce. After the open issues are solved to the satisfaction of the Release Team, the distribution is released. Releasing means that testing is renamed to stable, and a new copy is created for the new testing, and the previous stable is renamed to oldstable and stays there until it is finally archived. On archiving, the contents are moved to 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). Please refer to uploads to
the stable distribution for details.
Note that development under unstable continues during the freeze period, since the unstable distribution remains in place in parallel with testing.
Packages are usually installed into the `testing' distribution after they have undergone some degree of testing in unstable.
For more details, please see the information about the testing distribution.
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/ experimental main
deb-src http://ftp.xy.debian.org/debian/ 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 a 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.
When uploading to unstable a package which had bugs fixed in experimental,
please consider using the option -v to
dpkg-buildpackage to finally get them closed.
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'; Debian 3.0, `woody'; Debian 3.1, "sarge"; Debian 4.0, "etch". There is also a ``pseudo-distribution'', called `sid', which is the current `unstable' distribution; since packages are moved from `unstable' to `testing' as they approach stability, `sid' itself is never released. 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.
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 — a first tier of mirrors balances the load instead. 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.
The Incoming system is responsible for collecting updated packages and installing them in the Debian archive. It consists of a set of directories and scripts that are installed on ftp-master.debian.org.
Packages are uploaded by all the maintainers into a directory called
UploadQueue. This directory is scanned every few minutes by a
daemon called queued, *.command-files are executed,
and remaining and correctly signed *.changes-files are moved
together with their corresponding files to the unchecked
directory. This directory is not visible for most Developers, as ftp-master is
restricted; it is scanned every 15 minutes by the katie script,
which verifies the integrity of the uploaded packages and their 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 (or it has new binary packages), it is moved to the new
directory, where it waits for approval by the ftpmasters. If the package
contains files to be installed "by hand" it is moved to the
byhand directory, where it waits for manual installation by the
ftpmasters. Otherwise, if any error has been detected, the package is refused
and is moved to the reject directory.
Once the package is accepted, the system sends a confirmation mail to the
maintainer and 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/ until
it is really installed in the Debian archive. This happens only once a day
(and is also called the `dinstall run' for historical reasons); the package is
then removed from incoming and installed in the pool along with all the other
packages. Once all the other updates (generating new 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 [email protected].
If a package is released with Distribution: set to `unstable' or
`experimental', the announcement will be posted to [email protected]
instead.
Though ftp-master is restricted, a copy of the installation is available to all developers on merkel.debian.org.
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 tracks bugs for each package. You can view the bugs of a given package at the URL http://bugs.debian.org/package-name.
madison utility
madison is a command-line utility that is available on
ftp-master.debian.org, and on the mirror on
merkel.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 version of the package has been recompiled on most of the architectures.
The Package Tracking System (PTS) is an email-based tool to track the activity of a source package. This really means that you can get the same emails that the package maintainer gets, simply by subscribing to the package in the PTS.
Each email sent through the PTS is classified under one of the keywords listed below. This will let you select the mails that you want to receive.
By default you will get:
All the bug reports and following discussions.
The email notifications from [email protected] about
bug report status changes.
The email notification from katie when an uploaded source package
is accepted.
Other warning and error emails from katie (such as an override
disparity for the section and/or the priority field).
Any non-automatic email sent to the PTS by people who wanted to contact the subscribers of the package. This can be done by sending mail to sourcepackage@packages.qa.debian.org. In order to prevent spam, all messages sent to these addresses must contain the X-PTS-Approved header with a non-empty value.
Mails sent to the maintainer through the *@packages.debian.org email aliases.
Regular summary emails about the package's status. Currently, only progression in testing is sent.
You can also decide to receive additional information:
The email notification from katie when an uploaded binary package
is accepted. In other words, whenever a build daemon or a porter uploads your
package for another architecture, you can get an email to track how your
package gets recompiled for all architectures.
VCS commit notifications, if the package has a VCS repository and the maintainer has set up forwarding of commit notifications to the PTS. The "cvs" name is historic, in most cases commit notifications will come from some other VCS like subversion or git.
Translations of descriptions or debconf templates submitted to the Debian Description Translation Project.
Information about changes made to the package in derivative distributions (for example Ubuntu).
You can control your subscription(s) to the PTS by sending various commands to
[email protected].
Subscribes email to communications related to the source package sourcepackage. Sender address is used if the second argument is not present. If sourcepackage 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.
Removes a previous subscription to the source package sourcepackage using the specified email address or the sender address if the second argument is left out.
Removes all subscriptions of the specified email address or the sender address if the second argument is left out.
Lists all subscriptions for the sender or the email address optionally specified.
Tells you the keywords that you are accepting. For an explanation of keywords, see above. Here's a quick summary:
bts: mails coming from the Debian Bug Tracking System
bts-control: reply to mails sent to [email protected]
summary: automatic summary mails about the state of a package
contact: mails sent to the maintainer through the *@packages.debian.org aliases
cvs: notification of VCS commits
ddtp: translations of descriptions and debconf templates
derivatives: changes made on the package by derivative distributions
upload-source: announce of a new source upload that has been accepted
upload-binary: announce of a new binary-only upload (porting)
katie-other: other mails from ftpmasters (override disparity, etc.)
default: all the other mails (those which aren't "automatic")
Same as the previous item but for the given source package, since you may select a different set of keywords for each source package.
Accept (+) or refuse (-) mails classified under the given keyword(s). Define the list (=) of accepted keywords. This changes the default set of keywords accepted by a user.
Accept (+) or refuse (-) mails classified under the given keyword(s). Define the list (=) of accepted keywords. This changes the set of accepted keywords of all the currently active subscriptions of a user.
Same as previous item but overrides the keywords list for the indicated source package.
Stops processing commands. All following lines are ignored by the bot.
The pts-subscribe command-line utility (from the
devscripts package) can be handy to temporarily subscribe to some
packages, for example after having made an non-maintainer upload.
Once you are subscribed to a package, you will get the mails sent to
sourcepackage@packages.qa.debian.org. Those mails have
special headers appended to let you filter them in a special mailbox (e.g.
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: [email protected]
X-PTS-Package: dpkg
X-PTS-Keyword: upload-source
List-Unsubscribe: <mailto:[email protected]?body=unsubscribe+dpkg>
If you use a publicly accessible VCS repository for maintaining your Debian package, you may want to forward the commit notification to the PTS so that the subscribers (and possible co-maintainers) can closely follow the package's evolution.
Once you set up the VCS repository to generate commit notifications, you just have to make sure it sends a copy of those mails to sourcepackage[email protected]. Only the people who accept the cvs keyword will receive these notifications. Note that the mail need to be sent from a debian.org machine, otherwise you'll have to add the X-PTS-Approved: 1 header.
For Subversion repositories, the usage of svnmailer is recommended. See
http://wiki.debian.org/Alioth/PackagingProject
for an example on how to do it.
The PTS has a web interface at http://packages.qa.debian.org/
that puts together a lot of information about each source package. It features
many useful links (BTS, QA stats, contact information, DDTP translation status,
buildd logs) and gathers much 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 allows easy subscription to the PTS via email.
You can jump directly to the web page concerning a specific source package with a URL like http://packages.qa.debian.org/sourcepackage.
This web interface has been designed like a portal for the development of packages: you can add custom content on your packages' pages. You can add "static information" (news items that are meant to stay available indefinitely) and news items in the "latest news" section.
Static news items can be used to indicate:
the availability of a project hosted on Alioth for co-maintaining the package
a link to the upstream web site
a link to the upstream bug tracker
the existence of an IRC channel dedicated to the software
any other available resource that could be useful in the maintenance of the package
Usual news items may be used to announce that:
beta packages are available for testing
final packages are expected for next week
the packaging is about to be redone from scratch
backports are available
the maintainer is on vacation (if they wish to publish this information)
a NMU is being worked on
something important will affect the package
Both kinds of news are generated in a similar manner: you just have to send an
email either to [email protected]
or to [email protected]. The
mail should indicate which package is concerned by having the name of the
source package in a X-PTS-Package mail header or in a
Package pseudo-header (like the BTS reports). If a 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.
Here are a few examples of valid mails used to generate news items in the PTS. The first one adds a link to the cvsweb interface of debian-cd in the "Static information" section:
From: Raphael Hertzog <[email protected]>
To: [email protected]
Subject: Browse debian-cd CVS repository with cvsweb
Package: debian-cd
Url: http://cvs.debian.org/debian-cd/
The second one is an announcement 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 <[email protected]>
To: [email protected]
Bcc: [email protected]
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 item to the PTS because you won't be able to remove it later and you won't be able to edit it either. The only thing that you can do is send a second news item that will deprecate the information contained in the previous one.
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 bugs, and so that you don't forget which packages are your responsibility.
Alioth is a Debian service based on a slightly modified version of the GForge software (which evolved from SourceForge). This software offers developers access to easy-to-use tools such as bug trackers, patch manager, project/task managers, file hosting services, mailing lists, CVS repositories etc. All these tools are managed via a web interface.
It is intended to provide facilities to free software projects backed or led by Debian, facilitate contributions from external developers to projects started by Debian, and help projects whose goals are the promotion of Debian or its derivatives. It's heavily used by many Debian teams and provides hosting for all sorts of VCS repositories.
All Debian developers automatically have an account on Alioth. They can activate it by using the recover password facility. External developers can request guest accounts on Alioth.
For more information please visit the following links:
Since October of 2002, HP has sponsored a subscription to LWN for all
interested Debian developers. Details on how to get access to this benefit are
in http://lists.debian.org/debian-devel-announce/2002/10/msg00018.html.
[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ A ] [ next ]
Debian Developer's Reference
[email protected]