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

Re: The road ahead ...

Steve Dunham wrote:
> Christian Meder <meder@isr.uni-stuttgart.de> writes:
> > Hi,
> > this is just a summary of the current Sparc slink status:
> > * boot floppies
> > Seem to work pretty well. Some devices for a working X setup are missing
> > from the initial installation (sunmouse, fb*, kbd; known by Eric). Eric,
> > could you incorporate a generic-sparc target in the makedev package and
> > upload it too (or provide the patches to the list) ?  On a SS10


> > I had problems using the bootfloppies because every command issued in ash
> > was segfaulting (ash_0.3.4-6.2 uploaded yesterday fixes the symptoms but I'm 
> > not sure why ;-) Eric, could you test the new ash and include it in the
> > next boot floppies release (it's mandatory for the two SS10 we got around)


> Also, Eric seems interested in making everything work on both
> UltraSparc's and Sparcs, so I'm going to work with him on this.
> > * X
> > Seems to work well on most installations. I uploaded the last X packages and 
> > didn't file a bug report with the patch but sent it to Anders who 
> > usually does the X stuff on Sparc. I didn't keep up with the latest X 
> > prereleases on i386 but we definitly need another X upload after Branden
> > released another X set. Anders, Steve, could you coordinate on syncing up
> > with Branden's prereleases ? I would favor to use the current X sparc patch
> > for frozen and switch to Steve's patches for potato.
> My packages still need some polishing, but they add Mach64 and
> UltraSparc support.  Maybe we should add my Mach64 and XSun24 servers
> to the CDROM, in a seperate directory, as a convenience?

BTW, is the missing source for X problem was resolved in slink ?

> > * kernel issues
> > 2.0.35 was running pretty well for me. I'm running a 2.2.0-pre8 cvs kernel 
> > right now which is up 6 days. Anyone experiences with 2.2.0 ?
> > If we'll agree on a good 2.2.x candiate I'll package it and upload an image.
> > Probably we should provide 2.2.x boot images too. What's your opinion Eric ?
> IMHO, this should be 2.2.0 with David Millers patches from
> ftp.kernel.org, plus a very small Ultra patch that he just posted,
> which fixes fakeroot and postgresql on Ultrasparcs.

I will try to add 2.2 kernel support to bootdisks at the end of this week.

What should we do about kernel:
 1. release slink with 2.0.35 bootdisks and 2.2 as alternate boot method [*]
 2. release slink with 2.2 bootdisks

BTW, what is the deadline for release ?

[*] I don't know wether I will be able to merge both boot methods in one
disks set.  A more simpler way could be to release 2 independent set of
bootdisks (rescue & drivers floppy disks are already distincts, therefore I
only need to add another root floppy disk for 2.2).

> If we make this package, we should try to do it right.  If you install
> "egcs64_19980921-2" and the binutils from my ftp site, then you can
> generate both sparc64 and sparc kernels on any machine.  (Just supply
> "ARCH=sparc64" to the "make" command.)  It would be nice if we made
> the package properly generate both kernels.
> After slink, we can look into adding smp kernels to the list. (I'd
> propose kernel64-image for the 64bit kernel, unless somebody has a
> better idea.)
> > * outdated and missing packages
> > I've got most of the outdated stuff compiled and will upload it today or
> > tomorrow (hope I will get Gnome done too ;-)
> > * testing
> > I would appreciate a flood of experiences with the uptodate sparc slink 
> > distribution. Serious brokenness is especially welcome but we like 
> > supportive cheers too ;-)
> * binutils
> One other, minor issue is binutils.  I have a small patch to both the
> rules file and the sparc64 parts of binutils that enable it to compile
> the sparc64 kernel (without changing it's ability to build sparc32
> stuff).  While it would be nice to have in slink, it might not be
> worth the trouble of changing a source package.

If the sparc distribution have to run on both sparcs & ultras, it will be
required for user to build new kernels, therefore it should appear on the
Either discuss this with the package maintainer, or upload it as separate
source (eg. binutils-sparc64-linux like the already existing
binutils-m68k-linux package).
IMHO, if it only fixes problem in the sparc64 part, it could be merged to our
main binutils package.


 Eric Delaunay                 | "La guerre justifie l'existence des militaires.
 delaunay@lix.polytechnique.fr | En les supprimant." Henri Jeanson (1900-1970)

Reply to: