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
signature.asc
Description: Digital signature
