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.
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?
Based on these xulrunner build times, we'd need an arm box that's 4x as
fast as the current one to be "competitive":
i386 0:42 (amd64 is of course approx. the same)
alpha 1:02
s390 1:10
sparc 1:59
ia64 1:19
hppa 2:39
powerpc 2:45
mips 3:09
mipsel 3:19
arm 13:01
m68k 46:22 (build failed incomplete)