Re: Release plans for potato/m68k?
> With the potato freeze date approaching rapidly, I'm beggining to wonder
> about our plans for the m68k port in the next release. Specifically:
>
> 1) What version of libc will we be going with?
2.1 I thought, but Roman is the one to comment on that. We'd be on our own
with all the minimal library stuff on the boot floppies in case we stay on
2.0...
> 2) What version of Linux will we be going with? The Macintosh definitely
> needs a 2.2 kernel, as none of the new features (colour framebuffer, network
> device support, ADB on the IIfx/Q900/Q950/Powerbook, etc) are in 2.0.36 nor
> are they likely to be back-ported.
I'm out of the loop WRT general release plans, but I sure hope that other
archs plan on using some 2.2.x version. I'd advise against using 2.0.36
(mainly because the last thing I did on 2.0.36 was to FUBAR the whole thing
with the new FPU emulator, and I haven't done a thing since).
> 3) Who is doing the boot-floppies? I remember that I volunteered to do them
> for the Macintosh, and I'm now setting up my build and test machines, but I
> need to coordinate with whoever does them for Amiga, Atari, MVME, and hp300.
Support for Amiga, Atari and VME was in the 2.1.9 boot floppies. I've never
seen hp300 support code. The way the boot-floppies package is (was) set up
it will build rescue and driver images for all supported machines automagically
and package the release files into tar or lha archives. lha is evil (or so I
heard) and may not be accepted anymore but I had added the tar option before
I last checked in the code. The real awkward part is the packaging of the
Mac files; I had a second machine running MacOS, copied the release files
into a separate directory, fetched them to the Mac, packed them with StuffIt
and wrote the .sit back (as macbinary). If you suspend the build before the
md5sums are calculated you can place the Install.sit into the release
directory and resume the build. A StuffIt packer for Linux never
materialized for all I know.
The base.tgz is the same for all machines anyway (or should be), and the
rescue/drivers build doesn't take all that much time per machine. I
volunteer to test the install procedure on Atari, and maybe we can coax
Christian to do the same on Amiga. Nick Holgate probably is the only one
with VME around?
So I guess what I say is: do we need multiple builders at all? Building
Amiga and Atari and VME sets wasn't much of an overhead for me. I assume
that nothing broke since the 2.1 release, of course. And I haven't followed
the fantasies about graphical install etc. anymore.
I can't seriously offer building Atari boot floppies before throughly
checking my Atari, and I don't have the disk space for such a big package at
the moment after my Syjet went out of the window.
> 4) How do we manage the different kernel-patches (the Mac will most
> definitely need an additional patch above and beyond Jes' kernel - we are
> merging only in 2.3)
Nick patched kernel-package or kernel-diff to always apply the vanilla m68k
patch (the Debian 2.2 kernel source probably won't include that) and
prompted the user about patching in the Mac patch. The main reason at that
time: head.S wasn't merged yet and the Mac head.S broke on Amiga. That's
solved now, right? So we could merge Jes' and the Mac patch and use that
unconditionally like the old m68k patch before.
Disclaimer: I've never built kernel packages the Right Way. Unpack some
other kernel package, replace kernel, modules and doc and repack with a new
name was easier.
Michael
Reply to: