Hi, On Thu Feb 15, 2007 at 13:13:36 +1000, Anthony Towns wrote: > -vote dropped > > On Wed, Feb 14, 2007 at 03:06:01PM +0100, Martin Zobel-Helas wrote: > > > Maintaining a buildd isn't trivial, there's: > > > > > > - making sure they don't get rooted, and their builds compromised > > > - keeping the chroot up to date > > > - keeping in sync with w-b / sbuild changes > > > - keeping in sync with the infrastructure upstream (building from > > > incoming, > > > access to the buildd.d.o, etc) > > > - keeping the hardware available and running > > > - keeping the buildd building packages that will work > > > > > > It's not /that/ hard either (even if it's not something I could do without > > > a chunk of learning), but basically, yeah there are technical constraints. > > > The only policy constraint is that we're aiming to keep the number of > > > buildds limited to two or three per architecture (where possible); the > > > social constraints are mostly about convincingly demonstrating that the > > > technical constraints will be met on an ongoing basis. > > i think someone running more than one autobuilder for more than _two_ > > years now (okay, not for the officical archive, but i see that as > > nonrelevant here) demonstrats very good that he mets your mentioned > > technical constraints. > > AIUI, Aurelian doesn't have the capability to run a non-emulated arm > buildd. While http://blog.aurel32.net/?p=25 is a good demonstration > of some things, I don't think it's the level of buildd we want for our > release architectures. > > In general, I could pretty easily imagine a buildd that fails every one of > those points still being suitable for a non-release arch for two years.
I didn't thought of Aurelien, but of a few other persons, who are acting as buildd maintainers for experimental and non-free packages. Martin -- [EMAIL PROTECTED] /root]# man real-life No manual entry for real-life -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
