Re: stable with 2.2.11 (was Re: Stable release management)
On Mon, Aug 23, 1999 at 03:37:33PM +0200, Christian Meder wrote:
> > This is completely untrue. In fact the slink sparc release was with a
> > 2.2.1 kernel _because_ it was more stable than the 2.0.x kernels for this
> > architecture.
>
> Sorry to say that your comment is only partially true ;-)
> The 2.2.1 kernel was added to the slink sparc release for two reasons:
>
> * sun4u (Ultra) support was only usable with > 2.1.x kernels
> * 2.0.35 had a slowdown kernel bug on some sparc cpu models which was
> only fixed in 2.1.x kernels
>
> On my Sparcstation10 2.0.35 was a perfectly stable kernel. Steve Dunham
> pushed 2.2.1 in to support the sun4u architecture and we weren't sure
> if it would work out well on all sparc cpu's because it was still brand
> new stuff when we released slink ;-)
Looks like stability reasons to me (atleast in the case of the sun4c slow
down issue).
Either way, even if 2.0.35 ok on your machine, it does not mean it's not
more stable across _all_ sun platforms, which IMO, wins by default.
> > In case you want to know, right now I plan on trying to push getting the
> > 2.1.2 glibc into the sparc/slink re-release simply because the 2.1pre
> > (2.0.105) is not as stable, and actually compiles binaries that aren't
> > binary compatible with other sparc distributions.
>
> Could you elaborate in which areas 2.0.105 is unstable ? I'd be pretty
> hesistant to upgrade glibc without some striking arguments (binary
> compatibility with other distributions is a somewhat weak argument as
> there's only RedHat in the sparc arena and RH5.2 was based on glibc2.0
> which is incompatible by design and RH6.0 is glibc2.1 which should be
> mostly compatible to 2.0.105). Besides we need to test first if there's
> a working upgrade path for 2.0.35 users when upgrading to glibc2.1.2. Last
> time I checked a 2.2.x kernel was a prerequiste for upgrading glibc2.1
> which should be fixed (the upgrade should be possible with a 2.0.35 kernel).
2.0.105 is a pre-release, for the most part it's imcomplete in certain
areas, and leaving our dist with it makes us one of those dists who
release with alpha/beta software as "stable". Anything compiled with this
version of libc wont run on RH's stock unpatched version of glibc 2.1 (not
because of RH, but because of certain issues with egcs and chown() blah
blah blah). Now the version we have in potato of libc and egcs (right now
gcc2.95) will not only run our old binaries, and run RH's binaries, it
also compiles binaries that run on the old slink system (99% atleast) but
also run on RH's sparc glibc 2.1 too. This is a major thing. There are
companies out there (I know from direct contact) that have held off using
Debian as their sparc/linux development platform because of this
incompatibility. I'm sure there are a lot of other non-commercial
developers that are in the same boat.
> Sparc needs an updated egcs and egcs64 package (important bug fixes,
> miscompilation of 2.2.x kernels) and a
> newer kernel (although 2.2.9 should be fine). Additionally I would like to
> sync the source packages in the update, sparc has got a few .1 packages
> which can't be build from the corresponding source packages without a
> patch (the patches weren't included by the maintainers in time for the
> release). The Xsun24 should be updated (Steve incorporated the relevant
> patches in the potato package) because the Creator graphics board support
> is sooooooooo slow in slink.
> That's my wishlist ;-)
egcs64 is up to date and compiles kernels fine. gcc 2.95.1pre is in the
potato archive. As far as some of the .1 NMU packages, that will need to
be scripted out. The wanna-build db reports a surprisingly syncronised
dist on our part for slink with a few exceptions. Steve and Branden have
been working together on the X and Creator support (Creator support _will_
require a fairly new 2.2 kernel according to Steve).
As far as the support for 2.0.x support in glibc, that's what got us the
problem with 2.0.105's binary incompatibility with stock libc's.
Personally I would not run a 2.0 kernel on a sparc any more because of all
the problems with libc/syscalls.
Ben
Reply to: