Re: Release plans for potato/m68k?
> > 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...
> We are still at 2.0, the only real problem I see now is a dependency problem
> with locales...
Yikes. That sounds like fun - switching now.
> Who tested glibc2.1 for m68k, I mean really tested it? I dont remember
> seeing any reports...
> (Maybe we can test in Oldenburg? I should really try to bring my machine.)
I should try to get a car, otherwise I can't bring more than a laptop.
> lha is still _the_ standard packer for Amiga... but I guess that problem
> will resurface...
Yep.
> How about: Short: TGZ - Tar Archiver and GZIP in one Script
> Hmm, freeware, but with restriction...
Needs pipes which aren't available in TOS :(
> Of course we can switch to Geek Gadgets software, which is as free as it can
> be, but then well need additional libraries installed just to unpack this
> one archive...
> Do we have to unpack the archive? On the CD it can be unpacked, on the ftp
> server, it can be tgz and we give some hints where to find unpacking
The problem was mainly with the CD build depending on lha, and that's solved
by building a tgz version in addition to the lha.
> software? Works, but makes things a little uncomfortable for the user.
> How is it working for DOS, are they using ZIP? Are they allowed to use ZIP?
> There is unzip for Amiga, too... but not so common.
Don't know, but we need something to pack first :-)
> > The base.tgz is the same for all machines anyway (or should be), and the
> It really is? Astonishing, I thought it contained some binaries... they are
> in root.bin?
Huh? Sure base2_2.tgz contains loads of binaries. It's the same for all m68k
machines. I never claimed it's the same as for Intel, etc.
> Sure I´ll make a testinstall, I can even burn test CDs (if somebody tells
> me what scripts to use or points me to the images). If anybody wants to join
> the tests in germany...
Testing base installs won't be a problem, for CDs we need the CD build
scripts - Chris should know where to get them.
> > that nothing broke since the 2.1 release, of course. And I haven't followed
> > the fantasies about graphical install etc. anymore.
> Didnt we push Chris L. into this? ;-)
Did we? Good.
> > 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.
> I did, I didnt find it too intuitive, I hope I still find my notes. The
> latest kernel I got to work is 2.2.10 though, and I am not too sure about
> virge patches in that kernel, I allways had to undo parts of them to get it
> booting on my machine. I didnt try 2.3 or 2.2.x (x > 10) yet... so which 2.2
> would we use, _if_ we switch to 2.2?
Seems 2.2.10 is it anyway
> I can hear James screaming allready, jumping out of the window... changeing
> gcc to egcs, libc6 2.0 to 2.1 _and_ the kernel to 2.2 just a few days before
> the freeze? QA in industry would not allow that, I fear.
No, but there would be proper resources allocated to ensure the basics are
done in advance. The Mac port uses 2.2.x since a few months now without
major breakage IIRC. And the initial 2.2 mm problems seem fixed now.
> BTW, did I tell that xfree has to be built with gcc272 to work? I wouldnt
> wonder if more such surprises are waiting for us if we switch glibc _now_.
The real question is: _can_ we release with 2.0?
> And who is really testing all the packages we are building?
I thought Roman runs all builds on kullervo under 2.1? But that doesn't help
with X and other funnies.
Time to freeze ...
Michael
Reply to: