Differences between revisions 10 and 11
Revision 10 as of 2011-10-26 15:22:37
Size: 4163
Editor: ?MathieuMalaterre
Comment:
Revision 11 as of 2012-06-06 12:05:08
Size: 4163
Editor: ?Alexander Pashaliyski
Comment: ot -> to
Deletions are marked like this. Additions are marked like this.
Line 8: Line 8:
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 ot other architectures in the first place. 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.

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.

buildd differences

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 (potentially not even the loopback). 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

See also

Please

help to complete this page towards something more usable ... thanks