Debian “testing” distribution

For basic, user-oriented information about the testing distribution,
please see the Debian FAQ.

An important thing to note, both for regular users and the developers of
testing, is that security updates for testing are not managed by
the security team. For more information please see the
Security Team's FAQ.

This page primarily covers the aspects of testing important to Debian
developers.

How testing works

The testing distribution is an automatically generated distribution.
It is generated from the unstable distribution by a set of scripts which
attempt to move over packages which are reasonably likely to lack release-critical
bugs. They do so in a way that ensures that dependencies of other packages
in testing are always satisfiable.

A (particular version of a) package will move into testing when it
satisfies all of the following criteria:

It must have been in unstable for 10, 5 or 2 days, depending on the
urgency of the upload;

It must be compiled and up to date on all architectures it has
previously been compiled for in unstable;

It must not have release-critical bugs which do not also apply to
the version currently in testing (see below for
more information);

All of its dependencies must either be satisfiable by
packages already in testing, or be satisfiable by the group
of packages which are going to be installed at the same time;

The operation of installing the package into testing must not break
any packages currently in testing. (See below for
more information.)

A package which satisfies the first three of the above is said to be a
Valid Candidate.

The update script shows when each package might move from unstable into
testing. The output is twofold:

The update excuses
[gzipped]:
list of all candidate package versions and the basic status of their
propagation into testing; this is somewhat shorter and nicer than

The update output
[gzipped]:
the complete, rather crude output of the testing scripts as they
recurse through the candidates

What are release-critical bugs, and how do they get counted?

All bugs of some higher severities are by default considered
release-critical;
currently, these are critical, grave and
serious bugs.

Such bugs are presumed to have an impact on the chances that the package
will be released with the stable release of Debian: in general, if a package
has open release-critical bugs filed on it, it won't get into testing, and
consequently won't be released in stable.

The testing bug count are all release-critical bugs which
are marked to apply to package/version combinations
that are available in testingfor a release architecture.

How could installing a package into testing possibly break other
packages?

The structure of the distribution archives is such that they can only
contain one version of a package; a package is defined by its name. So, when
the source package acmefoo is installed into testing, along with
its binary packages acme-foo-bin, acme-bar-bin,
libacme-foo1 and libacme-foo-dev, the old version is
removed.

However, the old version may have provided a binary package with an old
soname of a library, such as libacme-foo0. Removing the old
acmefoo will remove libacme-foo0, which will break any
packages which depend on it.

Evidently, this mainly affects packages which provide changing sets of
binary packages in different versions (in turn, mainly libraries). However,
it will also affect packages upon which versioned dependencies have been
declared of the ==, <= or << varieties.

When the set of binary packages provided by a source package change in
this way, all the packages that depended on the old binaries will have to be
updated to depend on the new binaries instead. Because installing such a
source package into testing breaks all the packages that depended on it in
testing, some care now has to be taken: all the depending packages must be
updated and ready to be installed themselves so that they won't be broken,
and, once everything is ready, manual intervention by the release manager or
an assistant is normally required.

If you are having problems with complicated groups of packages like this,
contact debian-devel or debian-release for help.

I still don't understand! The testing scripts say that this
package is a valid candidate, but it still hasn't gone into
testing.

This tends to happen when in some way, directly or indirectly, installing
the package will break some other package.

Remember to consider your package's dependencies. Suppose your package
depends on libtool, or libltdlX. Your package won't go into
testing until the right version of libtool is ready to go in with it.

In turn, that won't happen until installing libtool doesn't break things
already in testing. In other words, until all other packages which depend
on libltdlY (where Y is the earlier version) have been
recompiled, and all their release critical bugs are gone, etc, none of these
packages will enter testing.

Why is it sometimes hard to get Architecture: all packages
into testing?

If the Architecture: all package is to be installed, it must
be possible to satisfy its dependencies on all
architectures. If it depends on certain packages which only compile on a
limited set of Debian's architectures, then it can't do that.

However, for the time being, testing will ignore Architecture:
all packages' installability on non-i386 architectures. (It's a
gross hack and I'm not really happy to have made it, but there you go.
—aj)

My package is stalled because it's out of date on some architecture.
What do I do?

Check the status of your package in the
build log database.
If the package doesn't build, it will be marked as failed;
investigate the build logs and fix any of the problems that are caused
by your package's sources.

If you happen to notice that some architectures have built the new
version of your package, but it isn't showing up in testing scripts output,
then you just have to be a bit more patient until the respective buildd
maintainer uploads the files to the Debian archive.

If you notice that some architectures haven't built your new version of
the package at all, despite the fact you uploaded a fix for an earlier
failure, the reason is probably that it's marked as waiting for dependencies
(Dep-Wait). You can also see the list of these so-called
wanna-build states to make
sure.

These problems usually get fixed eventually, but if you've been waiting
for a longer period of time (say, two weeks or more), notify the respective
port buildd maintainer if such an address is documented on the
port web page, or the mailing list of the
port.

If you have explicitly dropped the architecture from the Architecture list
in the control file, and the package has been built for that architecture
before, you will need to request that the old binary package for this
architecture be removed from the archive before your package can transition to
testing. You need to file a bug against ftp.debian.org requesting removal of
the dropped architecture's packages from the unstable archive. Generally the
relevant porting list should be informed as a matter of courtesy.

Are there any exceptions? I'm sure acmefoo has just made
it into testing despite not satisfying all of the requirements.

The release manager can override the rules in two ways:

They can decide that the breakage caused by the installation of a new
library will make things better rather than worse, and let it go in
along with its flotilla of dependents.

They can also manually remove packages from testing that would be
broken, so that new stuff can be installed.

Can you provide a real, non-trivial example?

Here's one: when the source package apache is installed into
testing, along with its binary packages apache,
apache-common, apache-dev and apache-doc, the
old version is removed.

However, all Apache module packages depend on apache-common (>=
something), apache-common (<< something),
so this change breaks all of those dependencies. Consequently, all Apache
modules need to be recompiled against the new version of Apache in order
for testing to be updated.

Let's elaborate on this a bit further: after all of the modules have been
updated in unstable to work with a new Apache, the testing scripts try
apache-common and find out that it breaks all the Apache modules
because they have Depends: apache-common (<< the current
version), and then try libapache-foo to find
out that it doesn't install because it has Depends: apache-common (>=
the new version).

However, later they'll apply a different logic (sometimes prompted by a
manual intervention): they'll ignore the fact apache-common breaks
stuff, and keep going with things that work; if it still doesn't work after
we've done everything we can, too bad, but maybe it will
work. Later they'll try all the random libapache-foo
packages and see that they indeed work.

After everything's been tried, they check how many packages have been
broken, work out if that's better or worse than what there was originally
and either accept everything or forget about it. You'll see this in
update_output.txt on recur: lines.

For example:

recur: [foobar] baz

basically says having already found that foo and
bar make things better, I'm now trying baz to
see what happens, even though that breaks things. The lines of
update_output.txt that start with accepted indicate
things that appear to make things better, and skipped lines make
things worse.

The update_output.txt file is completely unreadable!

This means that if cln goes into testing, ginac-cint
and libginac-dev become uninstallable in testing on i386.
Note that the architectures are checked in alphabetical order and only the
problems on the first architecture with problems are shown — that's why
the alpha architecture is shown so often.

The got line includes the number of problems in testing on the
different architectures (until the first architecture where a problem is
found — see above). The i-45 means that if cln would go into
testing, there would be 45 uninstallable packages on i386. Some of the
entries above and below cln show there were 43 uninstallable
packages in testing on i386 at the time.

The skipped: cln (0) (150+4) line means that there are still 150
packages to go through after this package until this check of all packages
is completed, and that 4 packages have been found already that won't be
planned to be upgraded because they would break dependencies. The (0) is
irrelevant, you can safely ignore it.

Note that there are several checks of all packages in one testing
script run.

Nice web front-end to
help you find out why packages are being held out of testing

You might be interested in reading an older
explanation
email. Its only major flaw is that it doesn't take the package pool
into account, because that was implemented by James Troup after it was
written.