[buildd-tools-devel] Bug#859867: Bug#859867: Bug#859867: Please add a package which automatically configures sbuild for Debian packaging

[Geert Stappers]

On Sat, May 20, 2017 at 11:34:37PM +0200, Michael Stapelberg wrote:
> 
> Find attached the first draft of my suggestion. I implemented it as a
> separate package purely so that I can build it more quickly, but I assume
> we???d want to fold this into src:sbuild eventually.
> 
> The resulting package (I built it using dpkg-buildpackage -b) depends on
> sbuild, schroot, debootstrap, perl-base, lintian. Upon installation, it
> will create an unstable sbuild schroot, modify its configuration, add all
> users to sbuild and create a modified ~/.sbuildrc for all users.
> 
> If you want to read through the entire behavior, I recommend the
> entrypoints debian/postinst and update-sbuild-chroots.

the debian/postinst now here inline


#!/bin/sh

set -e

#DEBHELPER#

# TODO: make this package pass piuparts

# Add to group sbuild all “dynamically allocated user accounts”; see
# https://www.debian.org/doc/debian-policy/ch-opersys.html
for user in $(getent passwd | perl -F: -nlE '$F[2] >= 1000 && $F[2] <= 59999 && say $F[0]')
do
    # Strictly speaking, we should use sbuild-adduser, but sbuild-adduser prints
    # setup instructions to STDERR which do not make sense in the context of
    # this package. Filtering STDERR is cumbersome, so we call adduser directly.
    adduser --quiet -- "$user" sbuild
done

# TODO: maybe add a “setup” suffix into the generated chroot name for easier trouble-shooting (we’ll immediately know who created the chroot initially)

# Create a chroot if it does not already exist
chroot="unstable-$(dpkg --print-architecture)-sbuild"
if ! schroot -i -c chroot:${chroot} >/dev/null 2>&1
then
    sbuild-createchroot \
	--include=eatmydata,ccache,gnupg \
	unstable \
	/srv/chroot/${chroot} \
	http://deb.debian.org/debian

    # At this point, sbuild-createchroot created an schroot configuration with a
    # random suffix, e.g. /etc/schroot/chroot.d/unstable-amd64-sbuild-pyViYe. As
    # sbuild-createchroot recommends, we rename that file before making
    # adjustments.
    mv /etc/schroot/chroot.d/${chroot}-* /etc/schroot/chroot.d/${chroot}
fi

# schroot config customizations:
config=/etc/schroot/chroot.d/${chroot}
tmp=$(mktemp ${config}-XXXXXX.dpkg-tmp)
trap 'rm -f "${tmp}"' TERM INT EXIT QUIT

grep -v -E '^(aliases|command-prefix)=' "${config}" > "${tmp}"

# For convenience, treat UNRELEASED as an alias for unstable (so that
# debian/changelog files containing UNRELEASED do not need to be modified before
# building). Also sid, because it is short to type when specifying -d.
echo "aliases=UNRELEASED,sid" >> "${tmp}"

# Enable eatmydata: occasionally losing a test build is preferable over longer
# build times and disk wear.
echo "command-prefix=eatmydata" >> "${tmp}"

chmod 644 "${tmp}"
mv "${tmp}" "${config}"

# Copy a modified example sbuildrc config file
for homedir in $(getent passwd | perl -F: -nlE '$F[2] >= 1000 && $F[2] <= 59999 && say $F[5]')
do
    userconfig="${homedir}/.sbuildrc"
    if [ ! -e "${userconfig}" ]
    then
	(grep -v -E "^(# don't remove this|1;\$)" /usr/share/doc/sbuild/examples/example.sbuildrc && cat /usr/share/doc/sbuild-debian-setup/sbuildrc) > "${userconfig}"
    fi
done

# bind-mount the apt archive cache into chroots, so that packages are downloaded
# only once. The assumption is that users will not typically have a local apt
# mirror or caching proxy.
if ! grep -q '^/var/cache/apt/archives' /etc/schroot/sbuild/fstab
then
    echo "/var/cache/apt/archives /var/cache/apt/archives none rw,bind 0 0" \
	 >>/etc/schroot/sbuild/fstab
fi

if [ ! -e "/etc/schroot/setup.d/04tmpfs" ]
then
    echo ""
    echo "  If you can spare the RAM, you can enable building in tmpfs using:"
    echo ""
    echo "    sudo ln -s /etc/schroot/setup-available.d/overlays-in-tmpfs /etc/schroot/setup.d/04tmpfs"
    echo ""
fi

exit 0

> I tested this package on my notebook, which is a Debian installation on
> which I never had sbuild installed, so I???m reasonably confident that the
> package works ??? at least to the point that one gets an sbuild installation
> that builds packages.
> 
> I???d be happy about any feedback. Thanks!


What was/is the idea of doing this in an additional packages?
Why not in an additional script?


Groeten
Geert Stappers
-- 
Leven en laten leven