Re: armel boxes for Debian

[Moritz Muehlenhoff <jmm@inutil.org>]

On Wed, Feb 20, 2008 at 06:12:10PM -0500, Joey Hess wrote:
> Riku Voipio wrote:
> > The security buildd is a different story. Parallell buildd's compiling
> > several packages at time don't help[1], they want single builds
> > completed fast, so they can release security advisories with minimal
> > delay. For this reason, Moritz from the security team expressed
> > being unpleased with the speed of a Thecus and want something faster
> > as buildd.
> 
> I wonder if the security team is being entirely reasonable with their
> expectations for speed. The team typically wants to get a package built
> on all architectures before releasing an advisory, but since we don't
> have a rule that supported architectures all need to have hardware
> that's even within an order of magnitude of the speed of other
> architectures[2], isn't that a fundamentally unreasonable expectation for
> the security team to have?
> 
> Perhaps it would be better for them to develop policies to deal with
> slower architectures. Some currently fast-enough architectures will
> likely fall into the too slow category in years to come no matter what
> happens with arm now. New, faster alpha chips are not being designed,
> for example. One such policy might be to have a set of architectures
> that advisories are never delayed for.

We could just declare arm a second-class architecture for security updates,
i.e. DSAs being released once all archs are available except arm and arm
updates being released once available. For small to medium packages most
updates would still be released in sync, since we're not available to
release updates 24/7.

But we should stop withholding security updates because we wait on slow
archs. Debian was the first to fix the vmsplice root exploit. If we
had released all archs in sync we would have left most of our users
unprotected for two more days.
 
> I'm also unsure based on Moritz's mail exactly what kind of speed
> they're looking for from an arm security buildd. He mentioned something
> on the order of 14 hours to build xulrunner -- would an arm box that
> builds it in 9 hours[1] be a worthwhile improvement, or will that still
> leave the security team waiting until the next day for arm to catch up?

9 instead of 14 would still help. I also think a second security buildd
would help: It wouldn't address the spikes of giga packages like xulrunner,
but it would help for cases, where several updates are building in
parallel.

Cheers,
        Moritz