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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
