Re: Introductions, thoughts and observations ...
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
Reply to: