This is the Debian project ftp-master server. Various informational pages are available here.
Additional information is also available on FTPMaster wiki page.
Archive signing key
Information on the archive signing keys is available here
The ftpmaster team
The members of ftpmaster currently are divided into four groups, FTP Master, FTP Assistants, FTP Wizards and FTP Trainees.
Members of FTP Master are:
- Joerg Jaspert
- Mark Hymers
- Thorsten Alteholz
- Luke Faraone
The FTP Assistants are:
- Luca Falavigna
- Paul Tagliamonte
- Scott Kitterman
- Bastian Blank
- Sean Whitton
The FTP Wizards are:
- Mike O'Connor
- Torsten Werner
The FTP Trainees are:
- Utkarsh Gupta
- Filippo Rusconi
This information (and more like it) is available from Debian's Organizational Structure.
The FTP Master role, unix group debadmin, is responsible for:
- Keep the archive running
- Support the teams that depend on it (Release, Security, Backports)
- Keep the archive uptodate with the requirements of the project
The FTP Assistant role, unix group ftpteam, created in 2005, allows the addition of people to the FTP Team without having to hand out full FTP Master rights. It allows
- to process NEW,
- to handle overrides,
- to remove packages.
The FTP Wizard role consists of former team members, who are currently too busy to be actively involved in the above groups. But they carry valuable experience and can support us with their knowledge on IRC and mail and occasionally by direct actions on the machines.
The FTP Trainee role, group ftptrainee, was created in 2008 to allow easy training and testing of future team members. Trainees can look at NEW and do the usual package checks, but they can not actually accept or reject a package. Instead they leave a note, which an Assistant or Master reads and acts on.
dak (Debian Archive Kit) is the collection of scripts that have replaced dinstall and friends.
A developer-accessible read-only copy is available on
mirror.ftp-master.debian.org (accessible via SSH).
Log files can be found in
Uploads are first processed by debianqueued which also manages the deferred upload queue.
The source of debianqueued is part of dak;
log files can be found in
The dinstall portion of dak is run at the following times:
- 01:52 UTC
- 07:52 UTC
- 13:52 UTC
- 19:52 UTC
The status of the dinstall run can be checked by looking at https://ftp-master.debian.org/dinstall.status
There are currently 6 states it reports:
- Here we save a timestamp of our database (so we could go back using the WAL archiving), update various external resources like the i18n/ structure, move NEW accepted packages around and process new packages for proposed-updates.
- During that part we generate various files you can find in indices/ and prepare everything for the next state.
- Here we write out our Packages/Sources and Contents files.
- Directly after the packages files. Everything thats needed to finish the dists/ directory, like creating the (much hated) pdiff files as well as the release files. We also cleanup various things.
- We run various small actions in here, including the final preparation for the mirror tree, making all the changes visible to the world.
- From here on a lot of actions run in parallel. Basically general cleanup and householding actions that do not modify the visible archive.
- all done
- Who would have thought, we are all done.
New Packages uploaded to the archive, but not yet accepted, can be seen here. You can also look at the RFC822 version. Packages uploaded and accepted, but not yet installed into the pool locations are to be found here, until the dinstall cron run moves them into the pool.
A separate page exists for the NEW queue for Debian Backports.
There are graphs about various ftp-master queues available.
To find what packages (and why) have been removed you can view the log of removals. This log contains the entries for this year only, to view older removal log entries follow one of the following links. You can also look at the RFC822 version.
- log of removals for 2001 (RFC822 version)
- log of removals for 2002 (RFC822 version)
- log of removals for 2003 (RFC822 version)
- log of removals for 2004 (RFC822 version)
- log of removals for 2005 (RFC822 version)
- log of removals for 2006 (RFC822 version)
- log of removals for 2007 (RFC822 version)
- log of removals for 2008 (RFC822 version)
- log of removals for 2009 (RFC822 version)
- log of removals for 2010 (RFC822 version)
- log of removals for 2011 (RFC822 version)
- log of removals for 2012 (RFC822 version)
- log of removals for 2013 (RFC822 version)
- log of removals for 2014 (RFC822 version)
- log of removals for 2015 (RFC822 version)
- log of removals for 2016 (RFC822 version)
- log of removals for 2017 (RFC822 version)
- log of removals for 2018 (RFC822 version)
- log of removals for 2019 (RFC822 version)
- log of removals for 2020 (RFC822 version)
Additionally we provide a full log of all removals, in case you need to search in more than one year. Be careful, this file is huge (more than 31MB at the time of writing this). You can also look at the RFC822 version. Again, this file is huge (more than 23MB at the time of writing this).
If you want you can also follow removals via the RSS feed provided.
Some packages which needs to be removed manually are found in the cruft-report.
Bullseye is testing, sid is unstable. For more details please look at the testing pages.
Stable / Oldstable
Packages uploaded to proposed-updates which have not yet been accepted by the stable release managers can be seen here.
Packages uploaded to oldstable-proposed-updates can be seen here.
If your package has been rejected and you don't understand why, check the explanations of the sometimes cryptic rejection messages.
Packages failing a defined set of lintian tags will no longer be accepted into the archive, but get rejected immediately.
Those automated rejects will only be done on sourceful uploads to unstable and experimental.
As there are certain lintian tags that should only appear in very rare cases we have created two categories:
- Tags listed here *can* be overridden by the maintainer using the normal lintian override mechanism. Of course this should only be done if you have a technically sound reason why your package needs to break in such a way.
- Tags listed here can not be overridden. Those are tags corresponding to packaging errors serious enough to mark a package unfit for the archive and should never happen. In fact, most of the tags listed do not appear in our archive currently.
The current list of tags can be found here
Archive CriteriaCriteria for inclusion in the archive of new architectures.
Valid-Until and archived releases
Since wheezy the archive metadata has a field named
This field limits how long the metadata of the archive is
considered valid. It is simply a date and time, usually in
the future. This is automatically updated and renewed
whenever the relevant part of the archive receives an
When we archive a release and its associated suites, we are NOT removing this field from the metadata when it is there. That means that anyone who continues to use this archive from the archive of old releases will see apt refusing to use the release, due to it being expired.
This is NOT a bug, and we are NOT changing this.
If you really need to continue using an unsupported release,
you can tell apt to ignore the expiry with the option
apt in stretch and later can ignore this per entry in sources.list, use a format like the following:
deb [check-valid-until=no] http://YOURMIRROR/... yoursuite main
PHP LicenseStatement on the applicability of the PHP license for packages in Debian.
Patches for this website are welcome, please clone using:
git clone https://salsa.debian.org/ftp-team/website.git
Email contact: firstname.lastname@example.org
Request tracker: https://bugs.debian.org/ftp.debian.org (pseudo package)
Public IRC channel: #debian-ftp on irc.debian.org (OFTC)