Hi, > 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. Greetings 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]
