Hey Stephen, this is a draft of what I've been composing to send to
d-m68k. Its not done yet, but I'd like to get your opinions on it; I
need to lie down so I'll finish it tommorow. Thoughts, comments, etc.
welcome :-).
Michael
Hello all,
I'm new to this list, but I've recently started working on the m68k port
by hosting two buildds (hosted in Aranym, with distcc, and some scripts
to offload a lot of the heavy processing work to the more powerful host
machine with good success (diablos was able to go from eight hours
building zsh to two, and similar results on larger packages) and I'll be
adding two more relatively soon.
Anyway, I guess a short introduction is in order. I'm Michael, I've been
using Debian on and off for the last few years as a user. During the
last year or so, I've been been working on hurd-i386, working with their
ports and working on the mach microkernel, which taught me loads not
only about kernel development, but about Debian. While talking with ij
on helping buildd.net, he talked about some of the issues with m68k, and
I feel that my time can be better spent working here (not that I'm
leaving hurd-i386, just I rather help bring m68k as a release platform
in the hopefully semi-near future). I'm fairly well versed in porting to
new architectures (I did some of the work on the NSLU2 Unslung image in
its early days), and working in embedded processors (while m68k isn't
strictly an embedded machine, the speed and resources compared to
today's processors, its easier to think of it in this way). After
talking with Stephen about the history of the port in the last two
years, and ij, I've made some observations (note: some of this applies
more to embedded Debian architectures then m68k specifically, although I
also address coldfire)
- Catching up on unstable
Since m68k fell behind due to toolchain issues, we've been fighting an
uphill battle in an attempt to catch up with the rest of the archive. The
four new buildds I have work to offload a majority of the heavy processing
to the host machine, and with distcc and ccache to help speed up the process.
I've also included special shell scripts to offload things like texlive, docbook
and other processor intensive activities to the aranym host. This has drasticially
improved the packages per days of both cronos and diablos. At their peak, cronos
managed to build 16 packages within a 24 hour period, and diablos was able to build
21 within a 12 hour period (unfortunately, diablos has been grinding away building
gcc-snapshot for the last four days, and only just entered stage 3, so it won't be
available for a few more days for general package building). With two more autobuilders
promotheus, and hades coming up today, it should greatly accelerate the build process
(for anyone who is watching on buildd.net, my autobuilders, while listed, do not have w-b
access; they're feeding off a private w-b server with a package list provided by
Stephen. That list is available in Building under alexandria, the w-b server).
If anyone else would liake to use an old x86 or other machine running linux, I'm willing
to provide my aranym images for a quick turnkey setup of a new buildd.
- etch-m68k proposed updates
Since etch-m68k's release, we haven't released any updates for it, and thus anyone
using the current stable release has a fairly out of date system. During a conversation
with Stephen, I took it upon myself to create a w-b database that would allow us to
build the necessary updates. It came up with the following specs:
Total 9673 package(s) in state Installed.
Total 711 package(s) in state Needs-Build.
Total 10384 package(s)
(please note that I wasn't able to import NFU status into the DB, so these numbers
may not be fully accurate. This also includes non-free, and does not take account
any packages that have been built for unstable and made it into etch)
While I say catching up with unstable should be our priority, I also believe that it
would be greatly worthwhile to be able to release an update. It should be fairly easy
to generate another list of packages that have security updates, and build them in
addition to the list of purposed updates.
- m68k Testing
Building off my last point, it probably would beneficial to have a testing distro.
Personally, I tracking testing on any non-server machines as its up to date, and I've
never had random repository breaks from tracking it. The nice thing about testing is
that we don't need any additional resources or anything to build since update_out
simply takes the stable and old-Testing package files, and spits out the new Testing
package files. While the code that does this is fairly ... cryptic, I have managed to
use it to generate a somewhat working Testing distro (I've yet to manage to figure out
how to import debbugs into the format this code requires, I took one look at the BTS
backend database, and my eyes just kinda glossed over). If anyone is interested in
perusing in creating a testing distro, help would be appreciated in this matter.
- Coldfire
Well, any post about observations on this port is going to require talking about coldfire.
While I am not an expert in the architectural differences between a standard m68k processor
and coldfire, I do know that the two are not directly binary compatible, similar to the
differences between the various arm processors. It's probably within our best interests to
handle coldfire as a seperate port without sharing binaries; while it might be possible to
make this work since some of the more recent coldfire processors are fairly close to the base
m68k processor, it could also open an entire can of worms because it would mean that binaries
that work on these modern coldfire processors may fail to work on the earlier ones. By at the
very least having coldfire as a separate architecture, we can avoid these problems. In addition
since coldfire is identical to true m68k processors past the opcode level, its more of a matter
of recompiling everything for coldfire, and not truly a separate port in its own right.
Anyway, I think that's it for my introduction email. I'm sorry if I come off bossy or something, its
not my intent. Anyway, its nice to meet the rest of the people on this list :-).
Michael
Attachment:
signature.asc
Description: This is a digitally signed message part