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

Re: Introductions, thoughts and observations ...

Err, oops. I forgot to remove the header of this message; I sent a draft
to stephen earlier :-/.

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: