The autobuilder network is a Debian development that helps speed up package recompilations for all the architectures Debian currently supports. This network is made up of several machines that use a specific software package called buildd to pick up packages from the Debian archive and rebuild them for the target architecture.
The Debian distribution supports quite a few architectures, but the package maintainers usually only compile binary versions for a single architecture (usually i386). Developers for other architectures have to watch out for new versions of packages and recompile them if they want to stay up-to-date with the Intel distribution.
As Debian/m68k (the first non-Intel port) started, all this was done manually: developers watched the upload mailing list for new packages and took some of them for building. Coordination that no package is built twice by different people was done by announcing on a mailing list. It's obvious that this procedure is error-prone and time-consuming. This was, however, the usual way for keeping non-i386 distributions current for a long time.
The build daemon system automates most of this process. It consists of a set of scripts (written in Perl and Python) that have evolved over time to help porters with various tasks. They have finally developed into a system that is able to keep non-i386 Debian distributions up-to-date nearly automatically.
Buildd is the name usually given to the software used by the autobuilder network, but it's really made of different parts:
All these parts operate together in order to make the builder network work.
Actually, an average Debian developer does not need to explicitly use the buildd network. Whenever he uploads a package to the archive (binary compiled to a given architecture) it will be added to the database for all architectures (in state Needs-Build). Build machines will query the build database for packages in this state, and will routinely take packages from that list. The list is prioritized by previous compilation state, priority, section, and finally package name.
If the build succeeds in all architectures, the maintainer will not need to do anything. All those binary packages will be uploaded to the architecture main site. If the build does not succeed the package will enter a special state (Failed or Dep-Wait, if they depend on specific build dependencies which are not available). The autobuilder administrators will review packages which fail the build and will report back to the maintainer, usually, opening up a bug in the Bug Tracking System.
Sometimes a package takes a long time to build for a given architecture and that holds the package from entering testing. Unfortunately, the package will need to wait until a machine picks it up. Buildd administrators will not accept requests to speed up the building of a package since the priority list has already been established.
You can check that status of the different buildds attempt of the packages that belong to any given maintainer by checking the buildd logs. These logs are also linked from the Packages' Maintainer Overview.
For more information on the different states a package can be please read wanna-build-states.
Of course, both the documentation and the source code available for these different tools are the best way to find out how the buildd network works. Additionally, the Porting and being ported section of the Debian Developers Reference provides complementary information on how does it work and it also provides some information on package builders and porting tools which are involved in the process of both setting up and maintaining the buildd network.
There are some statistics available for the autobuilder network at the buildd stats page.
There are several reasons why a developer (or user) might want to setup and run an autobuilder:
You can read more information on how you can setup an autobuilder.
The admins responsible for buildd's for a particular arch can be reached at arch@buildd.debian.org, for example i386@buildd.debian.org.
This introduction to the autobuilder network was written with bits and pieces provided by Roman Hodek, Christian T. Steigies, Wouter Verhelst, Andreas Barth, Francesco Paolo Lovergine and Javier Fernández-Sanguino.