Re: mipsel drop / buildd situation Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space]
Op di, 08-03-2005 te 14:36 -0800, schreef Clint Byrum:
> On Tue, 2005-03-08 at 22:22 +0100, Wouter Verhelst wrote:
> > Op di, 08-03-2005 te 10:33 -0800, schreef Clint Byrum:
> > > How much would it help with the current problems if we just picked 3
> > > arches(mipsel, s390, ???)
> >
> > This argument has been brought up so many times by now that I'm amazed
> > people /still/ try it.
> >
> > The answer is, simply, 'not'. Go learn to use google if you want to know
> > why.
> >
>
> Good idea.. google is a great tool for this sort of thing. I put this
> one in:
>
> site:lists.debian.org architectures sarge debian-devel
>
> Lets see what some of the best hits were...
>
> http://lists.debian.org/debian-devel-announce/2004/08/msg00017.html
>
> "- Toolchain fixes. A misbuilt gcc-3.3 package on alpha left us with a
> broken compiler in sarge -- which aside from being release-critical,
> made it rather hard to build packages uploaded to the
> testing-proposed-updates queue. This is being addressed as we speak,
> though with a little more pain than we'd like; by dinstall on the 29th,
> we should have a working gcc on all architectures in sarge."
So, alpha broke here. Which didn't stall the release -- the main problem
back then was testing-proposed-updates.
> http://lists.debian.org/debian-devel/2003/05/msg01368.html
>
> "To fix the ptrace bug, the s390 and mips architectures rolled the ptrace
> security fix into kernel-patch-2.4.17-s390 and
> kernel-patch-2.4.{17,19}-mips. This makes things even worse, because if
> kernel-source-2.4.{17,19} are patched to contain the fix, it will almost
> certainly make these architectures' kernel images fail to build because of
> patch conflicts, and require that the -patch packages be updated _again_ to
> undo this."
So, mips and s390 broke here. Which didn't stall the release -- we
weren't close to release yet, back then.
> http://lists.debian.org/debian-devel/2004/04/msg01623.html
>
> "However, after fighting for months on an update for CAN-2004-0077 for
> all architectures and all kernels, it was a lot easier to provide
> updates for the CAN-2004-0109 vulnerability."
so, the way kernels were being maintained wasn't exactly optimal back
then.
> Nope.. nope.. there aren't too many architectures! You're right.
Shit happens. It's true that having more architectures require us to do
more work in some areas. It's not true that this has ever effectively
stalled our release, however, and it certainly does not do so now -- in
other words, it does not 'help with the current problems' to just pick a
few architectures and drop the rest.
This horse has been beaten to death and beyond. Please.
--
EARTH
smog | bricks
AIR -- mud -- FIRE
soda water | tequila
WATER
-- with thanks to fortune
Reply to: