Re: [buildd] Etch?
On Mon, Aug 14, 2006 at 05:39:54PM +0200, Roman Zippel wrote:
> 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.
Security updates is the least of the problems. The security team has
stated on multiple occasions that they do not care how many ports are
available; provided the buildd machines work, it takes just as much time
for them to support 1 architecture as it would to support 27.
The main problem is the people who need to coordinate everything:
release managers, debian-installer authors, ftpmasters (who maintain
ftp-master.debian.org), etc. For them, especially the release managers,
the burden of maintaining an extra architecture increases
super-linearly. And then I'm even ignoring the porters themselves; we'd
suddenly have to support two ports, rather than one.
I can also tell you that it will not help to say "but it doesn't need to
be a release architecture".
First, there's only so much time I can put in. I don't think I have the
time to support yet another port. I wouldn't mind dropping armeb and
start maintaining buildd hosts for a hypothetical CF port, but there
would be so much more to do; it wouldn't even remotely be enough. And I
hardly find the time to help track down m68k-specific bugs, for a port
which *isn't* even vapourware at this point; I don't think getting a
pure-coldfire port to work without dropping support for the regular m68k
port would be a task we could successfully accomplish.
Second, since we've had to endure this for a year now for the m68k port,
I can tell you that not being a release architecture makes the work for
a porter a *lot* harder. Your port suddenly isn't considered anymore for
testing transitions; this means that your "pre-release" version
(testing) becomes a lot less usable, since architecture-specific
release-critical bugs are ignored for your architecture.
Additionally, not being a release architecture means that bugs get lower
severities and, thus, sometimes lower priorities by maintainers.
ColdFire in Debian is going to be part of Debian/m68k, a separate port
done by someone else, or not supported by Debian at all.
Finally, again, I have thus far no reason to suspect that the difference
in performance is going to be very noticeable. The longer PLT section is
unfortunate, but there is no reason why the coldfire PLT implementation
could not be used for classic 68k, too. This will slow down things a
bit, but I dare say not incredibly.
Additionally, the reduction in performance will most likely be somewhat
ameliorated by a processor-specific C library for which we fully intent
to write support, too.
> > Supporting a Debian port requires processing time, disk space, and
> > bandwidth on ftp-master.debian.org.
>
> Are there some numbers about this?
I'm not really part of the FTP team, so I can't speak out of authority
here. However, last I heard, the numbers were something approximating
this:
* You need about 20-30G of disk space per architecture. This includes
not just the active .deb packages, but also the ones for testing and
(eventually) stable; additionally, files that are no longer in use
from Packages files are kept for a few days (I don't recall what the
reason was, but when I heard about that, it seemed a pretty good
reason to me). The amount of disk space required obviously increases
as time passes, and also variates depending on at what point in the
release we are (whether or not oldstable is still supported; how long
it's been since stable was released, (and thus how much difference
there is between stable and unstable), etc.)
* The daily mirror pulse takes somewhere between 200M and 2G each day;
there is no reason to assume that another architecture would increase
that number by anything else than 1/12th of this. As a side note,
however, I can mention that m68k usually does not keep up on busy (2G)
days.
There's a graph somewhere on ftp-master.debian.org, linked to from
http://buildd.debian.org/
* The daily cronjob takes hours, at least. I'm not sure about the exact
numbers, but they can be impressive; I don't think half a day or more
is unheard of. Adding an architecture only increases that number.
Obviously these problems can be solved, usually just by replacing
ftp-master.debian.org by beefier hardware. However, because these
numbers are so high, it is preferred that we do not try to create
another architecture if it isn't absolutely necessary to get this
support to work.
I'm quite sure that "There will be some slowdown" isn't going to be a
good argument against the above. "There will be significant slowdown"
might be, but based on what I've been doing so far, I don't think that
is going to be the case.
I understand why you don't want this; and frankly, I agree. But Debian
is not Gentoo or NetBSD. For either of those, it's not very hard to
support an extra architecture, so they might very well do it without
thinking much about it. Hell, NetBSD used to have support for a piece of
hardware of which only some 200 machines were ever made.
Debian, however, cannot think the same way, since adding another
architecture requires far more manpower and far more resources than is
the case for Gentoo or NetBSD.
Besides, I'd think it'd be cool if Gentoo were to have m68k support; it
would be great for those people interested in it. And there, you could
just say "CFLAGS=-m68040" and be done with it. Or so.
> 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.
That may all be true, but I prefer to leave the decision of whether or
not something is actually useful to our users.
In the case of the dbg packages, I will tell you that they are not, at
all, unusable; on the contrary. These packages currently only contain
the debugging information that gdb can use if it's not embedded in the
binary itself; they allow us to inspect core dumps and the like without
requiring separate binaries.
> > * 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,
Yeah, glibc is the main reason why 2.2 and 2.4 are being kicked out of
unstable right now.
> 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.
Right.
--
Fun will now commence
-- Seven Of Nine, "Ashes to Ashes", stardate 53679.4
Reply to: