[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Introductions, thoughts and observations ...

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 :-).

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 :-).

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: