Re: [buildd] Etch?
Hi,
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: