buildd - autobuilders
Once they are uploaded to the servers, new Debian packages build without manual intervention on all the many platform that Debian supports ... and on some that it does not support. A daemon performing the building on a particular platform is referred to as the 'buildd'. Every upload to sid that is not for the platform "all", i.e. platform-independent, will be passed to each of the build daemons to become coherently accessible for all platforms.
Every user of Debian can set up such a build daemon. But only registered Debian developers can upload the resulting packages to the distribution. For practical reasons, it is hence commonly a Debian developer who runs the buildd.
main / contrib / non-free
Debian aims at providing free software, with free as in "constrained only by skill" for modifyability, not just gratis software. The motivation to run software that is not free or that needs non-free components to be useful or to be built, i.e. that are outside of main, is not close to the heart of Debian developers. Also, not every non-free software is allowed to be ported to other architectures in the first place.
Maintainers of non-free packages that require their software to be auto-built on other platforms than their own, may however request help from a special network of non-free autobuilders. Verbose instructions are laid out in the announcement referenced below. Please keep in mind that these folks behind the non-free autobuilders have some pleiotropic appearance in the Debian community and it may take a few days to weeks until you receive a reply.
There are several circumstances about building under a buildd that are different from most built-by-hand environments. It's worth being aware of them, since they may cause your package to fail to build on the buildd network even though it builds fine for you from a shell. Note that if your package has a test suite that runs at build time, these constraints apply to the test suite as well as the build process itself:
no network -- most buildds will have no network access available. Your package build+test process must not attempt to use the network or assume that any network interface is available.
no tty -- packages built on a buildd have no controlling tty attached. So if any of the code in your build+test process behaves differently when it has a tty attached, the buildd will exercise a different code path than when you build from a terminal by hand.
default shell -- the non-privileged user will probably have /bin/sh as their default shell, and /bin/sh on the buildd is likely to be set to /bin/dash. Make sure that if your build+test process needs a more capable shell than dash, it explicitly declares the shell it needs.
pristine environment -- the buildd runs with a very minimal/stripped-down environment; the shell in your terminal emulator might have a very rich environment. schroot itself has an environment filter of ^(BASH_ENV|CDPATH|ENV|HOSTALIASES|IFS|KRB5_CONFIG|KRBCONFDIR|KRBTKFILE|KRB_CONF|LD_.*|LOCALDOMAIN|NLSPATH|PATH_LOCALE|RES_OPTIONS|TERMINFO|TERMINFO_DIRS|TERMPATH)$.
- please add other observations about buildd differences here!
To emulate some of the constraints of a buildd (no tty, default shell, pristine environment), you can try building your package like this:
env -i PATH=/usr/bin:/bin SHELL=/bin/sh dpkg-buildpackage -uc -us </dev/null
Pay attention that the email address is not .NET, see: upx-nrv for autobuilding
Official introduction to BuildDs, very useful for future buildd maintainers
help to complete this page towards something more usable ... thanks