On Tue, Apr 27, 2004 at 03:49:37AM +1000, Anthony Towns wrote:
> On Mon, Apr 26, 2004 at 06:08:34PM +0200, Wouter Verhelst wrote:
> > Maintaining a buildd machine involves keeping a chroot environment
> > relatively clean.
>
> Yup. Probably the best way of doing this is to debootstrap a new chroot
> every day.
Uh, I want to get some work done, too. Debootstrap on my m68k box takes
a few *hours* :-)
> One of the other tricks is that in some cases you probably need to install
> -dev packages from experimental, but in other cases you'd rather install
> the -dev packages from unstable.
Oh, right. Didn't even consider that problem.
> Experimental is kind-of "different" to unstable as far as buildding goes.
Absolutely.
> > [...]; as such,
> > the burden on the buildd maintainer will be a lot higher than it is on
> > an unstable buildd maintainer.
>
> Yeah; reducing this by offloading it to the package maintainer is a
> particularly good idea for experimental buildds (eg, mailing the build
> logs to the maintainer rather than the buildd operator; and having the
> maintainer sign the .changes files of successful builds).
This suggestion has been made before, but I'm not in favour of
implementing it. For one thing, handling the logs is by far the easiest
part of maintaining a buildd (signing a successful log takes a fraction
of a second for me, thanks to mutt remembering my gpg passphrase and
some scripts). For another, we have had quite some questions evolving
out of (understandable) ignorance regarding the buildd process, which is
one reason why I wrote http://people.d.o/~wouter/wanna-build-states;
becaue of that, I think that requiring individual maintainers to
understand how the buildd system works and to do "the right thing" upon
receipt of a buildd log might be too much to ask.
--
EARTH
smog | bricks
AIR -- mud -- FIRE
soda water | tequila
WATER
-- with thanks to fortune
Attachment:
signature.asc
Description: Digital signature