Maintainer | Sean Whitton <spwhitton@spwhitton.name> |
---|---|
Safe Haskell | None |
Language | Haskell98 |
Build and maintain schroots for use with sbuild.
For convenience we set up several enhancements, such as ccache and eatmydata. This means we have to make several assumptions:
- you want to build for a Debian release strictly newer than squeeze, or for a Buntish release newer than or equal to trusty
- if you want to build for Debian stretch or newer, you have sbuild 0.70.0 or newer (there is a backport to jessie)
The latter is due to the migration from GnuPG v1 to GnuPG v2.1 in Debian stretch, which older sbuild can't handle.
Suggested usage in config.hs
:
& Apt.installed ["piuparts", "autopkgtest"] & Sbuild.builtFor (System (Debian Linux Unstable) X86_32) Sbuild.UseCcache & Sbuild.piupartsConfFor (System (Debian Linux Unstable) X86_32) & Sbuild.updatedFor (System (Debian Linux Unstable) X86_32) `period` Weekly 1 & Sbuild.usableBy (User "spwhitton") & Sbuild.shareAptCache & Schroot.overlaysInTmpfs
If you are using sbuild older than 0.70.0, you also need:
& Sbuild.keypairGenerated
In ~/.sbuildrc
(sbuild 0.71.0 or newer):
$run_piuparts = 1; $piuparts_opts = [ '--schroot', '%r-%a-piuparts', '--fail-if-inadequate', '--fail-on-broken-symlinks', ]; $run_autopkgtest = 1; $autopkgtest_root_args = ""; $autopkgtest_opts = ["--", "schroot", "%r-%a-sbuild"];
We use sbuild-createchroot(1)
to create a chroot to the
specification of sbuild-setup(7)
. This avoids running propellor
inside the chroot to set it up. While that approach is flexible, a
propellor spin pulls in a lot of dependencies. This could defeat
using sbuild to determine if you've included all necessary build
dependencies in your source package control file.
Nevertheless, the chroot that sbuild-createchroot(1)
creates might
not meet your needs. For example, you might need to enable an apt
cacher. In that case you can do something like this in config.hs
:
& Sbuild.built (System (Debian Linux Unstable) X86_32) `before` mySetup where mySetup = Chroot.provisioned myChroot myChroot = Chroot.debootstrapped Debootstrap.BuilddD "/srv/chroot/unstable-i386" -- the extra configuration you need: & Apt.installed ["apt-transport-https"]
- data SbuildSchroot = SbuildSchroot Suite Architecture
- data UseCcache
- built :: SbuildSchroot -> Url -> UseCcache -> RevertableProperty DebianLike UnixLike
- updated :: SbuildSchroot -> Property DebianLike
- piupartsConf :: SbuildSchroot -> Property DebianLike
- builtFor :: System -> UseCcache -> RevertableProperty DebianLike UnixLike
- updatedFor :: System -> Property DebianLike
- piupartsConfFor :: System -> Property DebianLike
- installed :: Property DebianLike
- keypairGenerated :: Property DebianLike
- keypairInsecurelyGenerated :: Property DebianLike
- shareAptCache :: Property DebianLike
- usableBy :: User -> Property DebianLike
Creating and updating sbuild schroots
data SbuildSchroot Source #
An sbuild schroot, such as would be listed by schroot -l
Parts of the sbuild toolchain cannot distinguish between schroots with both the same suite and the same architecture, so neither do we
SbuildSchroot Suite Architecture |
Whether an sbuild schroot should use ccache during builds
ccache is generally useful but it breaks building some packages. This data types allows you to toggle it on and off for particular schroots.
built :: SbuildSchroot -> Url -> UseCcache -> RevertableProperty DebianLike UnixLike Source #
Build and configure a schroot for use with sbuild
updated :: SbuildSchroot -> Property DebianLike Source #
Ensure that an sbuild schroot's packages and apt indexes are updated
piupartsConf :: SbuildSchroot -> Property DebianLike Source #
Create a corresponding schroot config file for use with piuparts
This is useful because:
- piuparts will clear out the apt cache which makes
shareAptCache
much less useful - piuparts itself invokes eatmydata, so the command-prefix setting in our
regular schroot config would force the user to pass
--no-eatmydata
to piuparts in their~/.sbuildrc
, which is inconvenient.
To make use of this new schroot config, you can put something like this in your ~/.sbuildrc (sbuild 0.71.0 or newer):
$run_piuparts = 1; $piuparts_opts = [ '--schroot', '%r-%a-piuparts', '--fail-if-inadequate', '--fail-on-broken-symlinks', ];
This property has no effect if the corresponding sbuild schroot does not
exist (i.e. you also need built
or builtFor
).
updatedFor :: System -> Property DebianLike Source #
piupartsConfFor :: System -> Property DebianLike Source #
Create a corresponding schroot config file for use with piuparts
This function is a convenience wrapper around piupartsConf
, allowing the
user to identify the schroot using the System
type. See that function's
documentation for why you might want to use this property, and sample config.
Global sbuild configuration
installed :: Property DebianLike Source #
Ensure that sbuild is installed
keypairGenerated :: Property DebianLike Source #
Generate the apt keys needed by sbuild
You only need this if you are using sbuild older than 0.70.0.
keypairInsecurelyGenerated :: Property DebianLike Source #
Generate the apt keys needed by sbuild using a low-quality source of randomness
Note that any running rngd will be killed; if you are using rngd, you should arrange for it to be restarted after this property has been ensured. E.g.
& Sbuild.keypairInsecurelyGenerated `onChange` Systemd.started "my-rngd-service"
Useful on throwaway build VMs.
You only need this if you are using sbuild older than 0.70.0.
shareAptCache :: Property DebianLike Source #
Bind-mount varcacheaptarchives in all sbuild chroots so that the host system and the chroot share the apt cache
This speeds up builds by avoiding unnecessary downloads of build dependencies.