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

Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])

On Tue, Feb 22, 2005 at 03:09:55PM -0500, Joey Hess wrote:
> > > - security response time (more builds to do)

> > Which DSAs came out later than they should have because of this
> > supposed delay?  Nor could this possibly slow release.

> DSAs are occasionally delayed waiting on builds. The priveliged nature
> of much of the information surrounding DSAs makes it impossible for me
> to give a list, but I've seen it happen repeatedly. The most glaring
> example in recent memory is the 6 or so months it took for us to get
> updated kernels in stable for last spring's set of very bad kernel
> security holes.

> Security bugs which are currently not fixed in testing, and which either
> would be fixed there or would not be a concern if it wasn't for the need
> to support all architectures include:

Just so we're clear on *which* architectures are at issue here, and why they

>  bidwatcher 1.3.17-1 needed, have 1.3.16-1 for DSA-687-1

arm, sparc builds waiting on the xfree86 chroot cleanup

>  bind 1:8.4.6-1 needed, have 1:8.4.4-1 for CAN-2005-0033 

arm waits on cleanup of yacc alternative mess in buildd chroot

>  emacs21 21.3+1-9 needed, have 21.3+1-8 for CAN-2005-0100, DSA-685-1

m68k, mips builds missing due to a timestamp skew problem in the package
that constitutes a sourceful bug in emacs21 which affects slow architectures
*and all archs running 2.6 kernels* (hence amd64 fails, and after release
any buildds that switch to 2.6 kernels in sarge would fail)

>  kdeedu 4:3.3.2-2 needed, have 4:3.3.1-3 for CAN-2005-0011

mips, mipsel build of quantlib needed, requires adjusting buildd timeouts

>  kdelibs 4:3.3.2-2 needed, have 4:3.3.2-1 for CAN-2005-0365 

not actually an architecture stall problem anymore; this was a missing
mipsel build, but now it's that kdelibs is hung up waiting for aspell, which
is the sort of bad timing that can affect us at any moment (but is certainly
more likely when uploads to unstable for all archs are spread across a
longer period)

>  kernel-image-2.4.27-alpha (unfixed; bug #280492) for CAN-2003-0465

alpha, obviously

>  kernel-image-2.4.27-sparc 2.4.27-2 needed, have 2.4.27-1 for CAN-2004-1056, CAN-2004-1235

and sparc, of course

>  kernel-patch-powerpc-2.4.27 (unfixed) for CAN-2004-1056, CAN-2004-1235 


>  xemacs21 21.4.16-2 needed, have 21.4.16-1 for CAN-2005-0100, DSA-671-1

since resolved

>  xview 3.2p1.4-19 needed, have 3.2p1.4-16 for DSA-672-1

not actually an arch buildd problem, the issue here is that we have
known-broken binaries on one arch that need to be removed from the archive;
but if we count it, it counts for ia64.

So supposing we had some sort of requirement for release archs such as
"within 10 days of any source upload, there must be either a binary upload
or a FTBFS report for the build", we would presently have to kick out

  alpha amd64 arm ia64 m68k mips mipsel powerpc sparc

and keep

  hppa i386 s390;

and if we relax this to only require "within 10 days of any source upload,
assuming the source isn't buggy, there must be a binary upload for this
security bug", we would be kicking out

  alpha arm mips mipsel powerpc sparc

and keeping

  amd64 hppa ia64 i386 m68k s390,

which I hope amply demonstrates the point to people that railing against
slow or unpopular architectures is not actually going to bring about the
desired outcome.

Steve Langasek
postmodern programmer

Attachment: signature.asc
Description: Digital signature

Reply to: