Hello World,
A week ago we, that is, the m68k porters and some other people
interested in the port[1], held a weekend's meeting at the Christian
Albrechts University in Kiel, Germany. This was prompted by the fact
that the m68k port has been facing difficult problems in the past few
years, and we wanted an opportunity to discuss our respective ideas
about the port in person. In addition to this discussion, we also seized
upon the opportunity to do some porting work while there.
In light of the fact that the Debian/m68k port is going to be removed
from the archive, we had already been looking for alternatives. One of
the things we'll be doing is to move to debian-ports[2], a separate
archive network that is currently being used for the xBSD ports; we had
already decided upon that before the actual meeting, though.
The most pressing matter we discussed, however, has been what we thought
the best way to go forward was. Contrary to what some people may think,
the end of Debian/m68k on debian.org to us does not mean the end of the
Debian/m68k port as a whole; and while we may be having problems
currently, most of these problems are on their way to bein solved medium
to long term.
The problems that we were facing include:
First, there currently is no working TLS implementation for Linux/m68k.
This is being worked on by codesourcery, however, whose latest
projection predicts this to be ready by the end of the year.
Second, you may remember that a few years ago, Freescale kindly donated
us five ColdFire V4E evaluation boards[3]. Since then we tried to bootstrap
and get Debian booting on those boards. There was some good progress
lately, but knowledge about hybrid ports is still needed. So, if you
have any experience in this area, feel free to join us!
The approach of a hybrid port, as opposed to a two separate ports, was
originally chosen because of space considerations, amongst other
reasons. Since we're going to be going off the debian.org network now,
however, that last blocker is going away; and we've decided to reshuffle
some boards so that people with more free time can work on the port in
lieu of people who don't but still have a board. With this reshuffling,
we expect to be bootstrapping a ColdFire(-only) port over the next few
weeks.
As luck would have it, Freescale recently updated their Linux Board
Support Packages for their ColdFire offerings, updating the kernel to a
more recent version; this should make it easier for us to actually
bootstrap this port.
We're not yet decided on whether we'll pursue this hybrid port idea any
further once the ColdFire port has been set up; but we figure that as
we'll have to do such a ColdFire bootstrap anyway, we might just as well
do it now.
Thirdly, a problem that's been plagueing us for a very long time is the
lack of hardware of a decent speed that we can use to build our packages
on; this, in fact, was one of the reasons why I approached Freescale a
few years ago so as to receive the ColdFire boards, but as explained
above, that has so far not yet led to a solution. One way to remedy the
lack of speedy hardware is to run buildd inside of an emulator that can
run the hardware you're working on; that approach, however, is not
without its problems, as it is much harder to rule out bugs in a piece
of software that is constantly under development than it is to know
about a bad run of hardware; this may in rare occasions result in
sleeper bugs in compiled software, which are very hard to debug[4].
Given that some of the upstream developers of one m68k emulator in
particular, ARAnyM[5], are active on the debian-68k mailinglist,
actively supporting the use of Linux/m68k on their emulator; that this
emulator is Free Software and packaged for Debian; and that on modern
hardware this emulator is now capable of emulating m68k hardware at
somewhat higher speeds than actual m68k hardware, we decided that this
was worth the risk. We are, however, unanimously convinced that we
should never be fully dependent on emulated machines, even if the ARAnyM
emulator would be perfect[6].
Fourthly, we are going to attempt to provide a Lenny installation to our
users that would be as close as possible to the real Lenny available
from debian.org; and after the release of Lenny, we will try to provide
our own testing that will in some respects mirror Debian testing.
All those attending expressed a feeling that the meeting went well, and
that we appeared to be mostly in agreement about a great many things;
indeed, as Stephen said, this is the kind of consensus that is far
easier to reach when meeting in the flesh than would have been possible
through email or even over IRC.
The discussion about our future itself, and two talks that have been
held for some members of staff of the Christian Albrechts University,
have been videotaped and will shortly be placed on the
meetings-archive[7].
Greetings,
the Debian/m68k team.
[1] Attending were:
Wouter Verhelst, Debian Developer, Debian/m68k porter,
Stephen Marenka, Debian Developer, Debian/m68k porter,
Christian T. Steigies, Debian Developer, Debian/m68k porter and
organizer of the meeting,
Joey Schulze, Debian Developer, original proprietor of
kullervo.debian.org and past Debian/m68k porter; longtime
organizer of the (now defunct) Oldenburg meetings that initially
started as m68k porter hacksessions,
Roman Zippel, upstream Linux/m68k kernel hacker,
Carsten Schlote, embedded Linux developer focussing on ColdFire and
m68k-based hardware,
Ingo Juergensmann, who through his vast knowledge of Amiga hardware
has provided valuable help to the Debian/m68k port in the past,
Unfortunately, Ingo had to leave before we had been able to discuss
the matters at hand.
We'd like to thank the DPL for kindly agreeing to refund Stephen
Marenka's plane ticket with Debian money, allowing him to join the
meeting; and Christian Steigies for hosting, feeding, bedding, and
generally taking great care of us and for providing such nice
facilities.
Additionally, we had set up a live stream that allowed the following
people to join in through IRC:
Michael Schmitz, Debian Developer, Debian/m68k porter,
Geert Uytterhoeven, upstream Linux/m68k kernel hacker,
Joined through IRC at various times during the meeting, but could
not make it for the actual discussion:
Michael Casadevall, NM, Debian/m68k porter,
Simon Richter, Debian Developer, Emdebian developer.
[2] http://www.debian-ports.org/
[3] http://lists.debian.org/debian-devel-announce/2006/01/msg00005.html
[4] Software that fails to build (or segfaults during compilation, or
fails its own selftest) immediately signals that something is wrong;
this is much more interesting for a porter than software that
compiles, but does not work when installed (or, worse, does not work
correctly). You are enabling your packages' test suites, right?
[5] http://aranym.org/
[6] Which it currently isn't; there are some known bugs in the FPU
emulation. There are no known bugs in the main instruction set
emulation, however.
[7] http://meetings-archive.debian.net/pub/debian-meetings/
--
<Lo-lan-do> Home is where you have to wash the dishes.
-- #debian-devel, Freenode, 2004-09-22
Attachment:
signature.asc
Description: Digital signature