Err, oops. I forgot to remove the header of this message; I sent a draft to stephen earlier :-/. Michael
On Sun, 2008-02-24 at 17:05 -0500, Michael Casadevall wrote: > 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
