[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: armel boxes for Debian

Moritz Muehlenhoff wrote:
> 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.

Yeah, that's what I was suggesting.

> 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.

And that advisory was initially only released for alpha, i386, amd64, ia64,
and s390 -- so it wasn't only arm being too slow in that case. Perhaps
arm delayed the follow-up advisory though?

> > 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.

The benefits I see from such a speedup are that it would let the arm
advisory arrive 5 hours faster (but still 7 hours after everything
else), and that it would increase the number of packages that wouldn't
need a delayed advisory for arm. Accurate?

see shy jo

Attachment: signature.asc
Description: Digital signature

Reply to: