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

Re: [buildd] Etch?


On Fri, 11 Aug 2006, Wouter Verhelst wrote:

> > What problems would that be? Toolchain problems don't solve itself and 
> > the build speed doesn't seem to the biggest problem.
> [...embedded...]
> > The problem is that these users are not really visible, could Debian/CF 
> > meet the release requirements on its own?
> > I'd really prefer to keep this at least initially separate and worry about 
> > a possible merge later.
> You're not honestly suggesting that we try getting a separate port for
> Debian/CF, are you?

Well, I wouldn't exclude that possibility completely. Being a secondary 
port doesn't has to be necessarily something negative. The problem being 
here that the status of a "secondary port" is undefined.
A secondary port could accommodates the needs of a smaller port without 
overly affecting primary ports, e.g. security updates could be released as 
soon as they are ready for the primary ports.

> Supporting a Debian port requires processing time, disk space, and
> bandwidth on ftp-master.debian.org.

Are there some numbers about this?
I looked a little through some of the large packages, a lot of them are 
not even m68k specific, followed by a few dbg packages, which are likely 
to completely unusable on m68k. The largest package I found with some 
value is the gcc-snaphot package.

> * More importantly, currently half of our buildd park are macintoshes
>   that will not work with 2.6 kernels. 2.2 and 2.4 are scheduled to be
>   removed from unstable, a move which will likely occur this month,
>   maybe even this week. It will not take very long before glibc will
>   drop support for 2.2 and 2.4 kernels, mainly because the glibc
>   maintainers were amongst those asking for this change.
>   While we can theoretically keep running our macs on 2.2 kernels and
>   have them build packages, they will fail an ever-increasing number of
>   things, much like the xargs issue that we currently see on a fair
>   number of builds on 2.2 kernels. If our macs cannot run 2.6, we will
>   need to find replacement for these somehow. We do not have the surplus
>   buildd power to just forget about the 2.2-running machines and
>   continue with those machines that do run 2.6.

glibc might force us soon to drop 2.2/2.4 support, I don't think we're 
going to survive much longer without tls support. I'm looking into adding 
the support for it, but as a consequence we might have a complete ABI 
change ahead of us, which we could use to make the m68k a little faster 
(e.g. register arguments, better alignment) and not slower.

bye, Roman

Reply to: