-
Notifications
You must be signed in to change notification settings - Fork 5
Debian sbuild configuration
The detailed process of creating chroots suitable for schroot is covered in the sbuild documentation and amounts to using a tool like debootstrap to create a Debian build environment in a subdirectory (which may or may not be also the mountpoint of an LVM snapshot) and then configuring that chroot to have the relevant apt sources and pre-installed packages (e.g. build-essential, dpkg-dev, and fakeroot).
When setting up new chroots using debootstrap on squeeze or older, specify the --variant=buildd option.
sudo debootstrap --variant=buildd squeeze /srv/chroots/squeeze http://ftp.uk.debian.org/debian
NOTE: We no longer support squeeze.
For newer releases of Debian, use the sbuild tools which make using sbuild on those chroots much eaiser. See the sbuild-createchroot manpage for more information on the options, but the basic example for Debian unstable would be:
sudo sbuild-createchroot unstable /srv/chroot/unstable http://ftp.uk.debian.org/debian
NOTE: If you are trying to set up a Debian chroot on Ubuntu, and this isnt working, please see issue #138 https://github.com/nicholasdavidson/pybit/issues/138
If this is the first time you've setup sbuild, generate a key.
sbuild-update --keygen
If you are installing inside a VM, rng-tools can help provide enough entropy to complete the key generation. https://www.howtoforge.com/helping-the-random-number-generator-to-gain-enough-entropy-with-rng-tools-debian-lenny
Access the chroot with:
sudo schroot -u root -c unstable
(Use unstable-source if using LVM - see the schroot manpage.)
The pybit debianclient uses /usr/lib/pbuilder/pbuilder-satisfydepends-classic for the dependency resolution test, so the pbuilder package needs to be installed inside each build chroot.
apt-get --no-install-recommends install pbuilder
If a build client cannot use LVM, this pre-build dependency check will be turned off anyway as there is a risk that it may leave build-dependencies installed when using permanent chroots. (See https://github.com/nicholasdavidson/pybit/issues/61). This will mean that pybit may report a package as failing to build on such clients when what actually happened is that the package build-dependencies could not be resolved.
Initial debootstrap setup can provide files which then cause problems the first time that a core package is installed. So, as LVM is a fresh install each time, it is best to fix these problems in the LVM source before trying to do builds. Example packages: netbase (/etc/protocols). This is particularly likely when using debootstrap from stable to setup LVM chroots for unstable - debootstrap copies certain files from the host system into the new chroot but these files then differ from the ones packaged in unstable.
Everything in and beneath the pybit buildd directory (e.g. /home/buildd/pybit) needs to be owned by the buildd user used by sbuild.
The pybit client will expect to be able to use a chroot (or an alias for a chroot) which matches the suite specified in the build request.
If using version control hooks, this suite is likely to come from the Distribution field of the output of dpkg-parsechangelog. Ensure that any client has a suitable chroot listed in the output of schroot -l. The suite should specified in /etc/pybit/client/client.conf as this will determine which queues the client will use to receive build requests. Multiple suites are supported by appending multiple suites to suites key in client.conf.
For example
{ "suites": ["testing","stable","oldstable"] }The pybit build client can also handle a build-environment parameter which forms part of the name of the chroot. The typical use for this is to build packages on top of a defined build suite. e.g. for an internal suite which uses a Debian release to provide the core packages like dpkg-dev, gcc and debhelper. This allows jobs to be requested for the same source code from a non-Debian release against two different Debian releases to be used when the source code needs to be checked against an upcoming release or in preparation for a migration to a new Debian release. Such schroots would already have two apt sources - one for Debian (either a local snapshot or a full mirror) for the compiler and build tools and another for the non-Debian dependencies such as the custom user interface or other code which is expected to run on an installed Debian base. The client then needs to have one chroot for each supported combination. For a non-Debian release called foobar which contains code needing to be built in a Debian Wheezy and a Debian Sid environment, this would require two chroots, called foobar-wheezy and foobar-sid with the apt sources to match. Equally, the target repository now needs a foobar-wheezy suite and a foobar-sid suite so that devices can be switched from one suite to another to test migration paths.
For example
{ "suites": ["development-wheezy","development-sid","archive-squeeze"] }It is an error to specify a build environment without a suite.
If a build request specifies a suite but not a build environment, the build-environment is not used and the schroot aliases will need to determine the default build environment.
amd64 machines can trivially build i386 packages using a simple chroot and pybit-client can support this simply by editing the host_arch in the /etc/pybit/client/client.conf file.
There is a test script (/usr/share/pybitclient/buildd-test.py see #7) which can be used alongside a test schroot to run through the buildd commands and then do the upload. (What happens to that upload is dependent on the next step, it just sits in an incoming directory initially.)
Most sbuild chroots have some form of bind mounting of useful directories into the relevant chroots, created by editing /etc/fstab outside the chroots. Certain tasks may fail if the pybit buildroot directory is not visible inside the chroots; other packages may need a usable /dev and or /proc. For example:
$ schroot -c wheezy
user@buildd:~$ mount
warning: can't open /etc/mtab: No such file or directory
This output indicates that nothing is mounted inside the chroot - some packages may fail to build and some pybit operations (like checking the build-dependencies are available) may fail. If the pybit build directory is in the /home/ tree, it is only necessary to bind mount the pybit build directory, not the entirety of /home/.
Set up dput by editing /etc/pybit/client/dput.cf to provide a usable upload configuration. The format of this file is the same as ~/.dput.cf and is passed to dput using the -c option internally.
Ensure the daemon can upload:
sudo ssh -o IdentityFile=/home/<USER>/.ssh/id_rsa <USER>@<DESTINATION>
Where is something like buildd and something like mirror.domain
pybit clients are configured in dry_run mode initially. The final stage of setting up a particular client is then to edit /etc/pybit/client/client.conf to change dry_run to false:
"dry_run": false,