[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

Done.

> > 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)

Ok.

> 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
dist.
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.

Regards.

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


Reply to: