I’ve expanded a bit on my idea (that is, the sbuilder wrapper to help aid with managing more then one sbuild chroot), and it got out of hand very quickly.
It’s gone from one small shell script to a set of 8, and growing. Quickly.
Until I spin these off into their own repo, they’ll be in my dot-bin
Before getting too far, please relize this is only how I’m using sbuild. There are many other (more) sane configurations that you can (and should) use.
This was not made to be useful for anyone other then me :)
I’ve added the ability to use unionfs-fuse, set up a way to login interactively and a script to create new chroots without having them register as a global schroot.
Firstly, forgive me for my sins. This is all a huge hack, but it’s use isn’t the worst thing in the world.
As of the time of this writing, I now have a gcc and clang chroot for each of stable, testing and unstable.
Now — the big question — how do you use this. Rather, this is more of a how do I use sbuilder :)
Firstly, I’ve created a file for each schroot set that I’m using. Here’s
[sid] type=directory description=Debian sid/amd64 autobuilder directory=/var/sbuild/sid groups=root,sbuild root-groups=root,sbuild script-config=sbuild/config
It’s very similar to the one that sbuilder-createchroot creates.
If you’re just looking for aufs / unionfs support, keep in mind schroot has
some great support. check
man 5 schroot.conf.
Next, create a
dist.d directory in
/var/sbuild — such as
/var/sbuild/sid.d. In the future, this might get automagically created by the
sb-create script. For now, it just expects that exists.
The arguments for all the sb* commands is always in the order of variant, dist.
variant defaults to “generic”, which I’ve set as an alias to the generic chroot, and the dist defaults to “sid”. At some point, I’ll change the default to be the last UNRELEASED entry in the changelog.
So, to create a new chroot to become your clang chroot, you may choose to
invoke it as
sb-create clang, or more explicitly
sb-create clang sid.
To create a new chroot to become your stable / gcc chroot, you may create it
sb-create gcc stable.
After you have a chroot, you can start to use the
sbo is just a wrapper around the
sb script that sets an envvar to tell
sb-posthook to set up the unionfs overlay.
The unionfs overlay routine replaces the dist symbolic link (such as
/var/sbuild/testing) with a folder, and mounts the real chroot (such as
/var/sbuild/testing.d/testing-gcc) under the unionfs divert point (which is
/var/sbuild/testing.overlay.d/testing-gcc). This lets us make
sure the chroot is never affected by a routine build, even if it’s designed to
trash a chroot (unless, of course, it uses any number of ways to get outside the
chroot and trash the pristine directory — this is to prevent mistakes, not
By the way, for those interested, there’s a small issue with what I’m describing it’s very subtle. Basically, there’s a few assumptions made by how schroot operates, and handles “sessions”. Since it’ll keep stuff mounted if the session is still active, it makes purging all this a real … pain.
The magic behind the scripts is in the
sb-endsessions routine — which will
properly end all the schroot sessions for that dist, and since we have our own
high-level locking system, we shouldn’t have a situation where this kills off
The code (which might have issues) looks like:
SESSIONS=`schroot --all-sessions -l | grep "^session:$DIST-"` for session in $SESSIONS; do echo "W: Ending session $session" schroot -e -c $session done
By backing of schroot’s mounts, we can do our mounting / removing without worrying about klobbering schroot.
Now, there’s also the case of wanting to interactively log into a chroot.
For that, there’s
sb-maint, both take the usual variant / dist
sb-login logs in as the current user, and
sb-maint logs in as
the root user.
Eventually, I’ll be adding some scripts to upgrade all the build chroots for a dist at once.