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