Re: unexpected NMUs || buildd queue
Wouter Verhelst <wouter@grep.be> writes:
> On Sat, Jul 17, 2004 at 10:58:57AM +0200, Goswin von Brederlow wrote:
>> Wouter Verhelst <wouter@grep.be> writes:
>> > In any case, buildd doesn't write to disk what it's doing (the
>> > build-progress file is written by sbuild), so if it's aborted
>> > incorrectly (i.e., it doesn't have time to write a REDO file), that
>> > information goes lost.
>> >
>> > That's probably a bug, but once you know about it, it's easy to work
>> > around (it just means you have to clean up after a crash, but you have
>> > to do that anyway, so...)
>>
>> Which is one of the things realy screwed up on the buildd/sbuild
>> combination.
>
> What's your alternative?
>
> You have to clean out the chroot anyway when the system goes down
> unexpectedly, or anything horrible might happen. The alternative would
> be to clean out and rebuild the chroot automatically -- don't tell me
> multibuild tries to do that?
That depends on what method of chroot cleaning / regeneration is being
configured.
One option is to have a template chroot (as tar.gz for example) and to
untar that for every build anew. Cleaning is a simple rm.
Another option is to have an LVM volume and make a new snapshot of it
for every build. Cleaning removes the snapshot.
The current way corresponds best to having a fixed chroot and cleaning
via debfoster.
There is also the possibility of rebuilding the chroot from scratch
(which calls cdebootstrap and a few extra commands to configure the
chroot).
The build also has two levels of creating a chroot:
1. bootstraping a new template (which is usualy done with cdebootstrap
but could be untaring a meta template and updating it)
2. cloning a template for a specific build (which means untaring,
making a snapshot or linking the static template into the right place)
Under normal operation the buildd just clones a new chroot for every
build and removes it afterwards (debfoster and unlink for the static
case). If a chroot failure is detected (like repeated failures to
install or purge packages) the build will try to bootstrap a fresh
template and might stop if that fails or also doesn't work.
Most systems will no longer suffer from install/purge problems from
one build getting dragged into the next build. I expect using a tar.gz
template will be the most used config. Also a buildd should stop
before it runs amok and fails 200 packages. That is the plan anyway.
As a sidenote the build dir will be mounted into the chroot normaly
and umounted before cleaning up. So failed builds still remain when
the chroot is just wiped.
MfG
Goswin
Reply to: