In the past few days I have been messing around with
Linux namespaces,
and developed a little tool (
pflask) that automates the creation of
simple Linux containers based on them (a sort of
chroot(8) on steroids if you
will).
While the whole raison d' tre behind this project was "just because", and many
more mature solutions exist, I decided that it'd be nice to find an actual use
case for this (otherwise I tend to lose interest pretty quickly) so I wrote a
lil (and rather dumb)
pbuilder clone that uses pflask instead of chroot.
The nice thing about pflask is that, differently from e.g. LXC, it doesn't need
any pre-configuration and can be used directly on a vanilla
debootstrap(8)ed
Debian system:
$ sudo mkdir -p /var/cache/pflask
$ sudo debootstrap --variant=buildd $DIST /var/cache/pflask/base-$DIST-$ARCH
Where
$DIST and
$ARCH are e.g.
unstable and
amd64.
Once that's done just run
pflask-debuild on the package sources:
$ apt-get source somepackage
$ cd somepackage-XYX
$ pflask-debuild
The script will take care of creating a new container,
chroot(2)ing into it,
installing all the required dependencies, building and signing the package (it
also runs lintian!).
The main difference from pbuilder is that pflask will mount a copy-on-write
filesystem (using AuFS) on the / of the container so that any modification
(e.g. installation of packages) can be easily discarded once the container
terminates (similarly to what
cowbuilder(8) does, modulo the hardlinks hack).
Additionally, thanks to the mount namespace created inside the container, all
of this will be isolated from the host system and other containers, so that
multiple packages can be built simultaneously on the same base debootstrapped
directory.
Another possibility would be that of disabling the network inside the container
using a network namespace, in order to prevent the package build system from
downloading stuff from Internet while at the same time maintaining the network
active on the host system, but I haven't done any experiment in this direction
yet.
Note though that all of this is rather crude and experimental, but as a little
hack it seems to work rather well (YMMV).
Whilst anyone can inspect the source code of free software for malicious flaws, most software is distributed pre-compiled to end users. The motivation behind the Reproducible Builds effort is to allow verification that no flaws have been introduced either maliciously or accidentally during this compilation process.
As part of this project I wrote a script to determine which packages installed on your system are "reproducible" or not:
What happened about the 
due to some