Re: XFree86 184.108.40.206a-8pre9v6 at master.debian.org/~branden/xfree86
> The patches that I sent you should be completely safe. But the
> resulting packages have only been tested by me. (As I said, I took
> out the -pedantic flag on the altdev stuff - the other changes don't
> touch x86 at all.)
Right, at least my sparc patches really only deal with the Xsun server. I
guess yours are similar.
> BTW, There are two kinds of sparc64 support: usermode and kernel mode.
> Usermode stuff is a _long_ way off, currently Debian runs 32-bit sparc
> stuff on a 64-bit kernel. So Alpha patches don't help much there.
> The biggest issue on the 32-bit sparc is unaligned memory accesses.
Hmm, the alpha patches clean up many unaligned accesses, and since the
alignment requirements for the alpha are the same as for sparc (save 64bit
alignment on 32bit sparcs) the alpha patches should fix this too. I've been
planning to merge the patch sets (I do the alpha X packages too), just haven't
gotten to it yet (and I was sort of waiting to see if the central CVS archive
that was suggested was going to happen). Maybe this is a good time...
> I don't really want to step on any feet here, but it would be nice if
> we could get the X source for Sparc into slink - and get the
> UltraSparc support in there. (Eric plans on making the install work,
> so X support would be an added bonus.)
> Nontheless, the current sparc binaries are a built by Anders from a
> seperate tree. (Anders - my tree was made by merging the latest
> UltraPenguin patches - a superset of the Red Hat patches - into
> Branden's tree.) I would want some other sparc people to double check
> my packages, before we actually include binary packages from my code
> into slink.
Can you send me your patches? I suspect that a lot of them are the same (and
they aren't really mine, Mike Shuey did most of the original work on them),
since they too are based on Red Hat's. That way I can merge them (or I could
send you mine and let you do the merging, either is fine by me). Mainly what I
want to achieve is that we don't change the way Xsun work (i.e. where it finds
screens and such. It has been changing a bit, and I think I have a good method
> If Anders has a tree that matches Branden's recent trees, I'll defer
> to him (but ask that either he or I merge in the Mach64 and Creator
> patches), otherwise, I'd like to the goahead from Anders et al to use
> my stuff in slink (after appropriate testing).
My sparc tree is currently too out-of-date to really be considered matching
Branden's tree. My only concern with switching entirely is that we may loose
fixes that are in my tree but not in yours, thus I'd rather try and merge our
> It shouldn't matter
> too much (as long as the binaries work), since I believe Anders is
> planning on starting from scratch on the 3.3.3.x releases.
That's the idea, yes, since much of the code should be in 3.3.3.x already.
> (I'm 99% sure the binaries work, the only issues would be install
> script &c, and they are mostly copied from the current binary
> packages. Also, I have to add a hard-coded XF86Config to the Sparc
> Mach64 package - because XF86Setup doesn't work yet on the sparc
What problems does XF86Setup have on the ultras? I plan on fixing it to work
on the alpha (where the problem mainly consists of non-existance of
xserver-vga16, xserver-mono works, though probably not on TGA).
-- Of course I'm crazy, but that doesn't mean I'm wrong.
Anders Hammarquist | email@example.com
Physics student | Hem: +46 31 47 69 27
Chalmers University of Technology, G|teborg, Sweden | Mob: +46 707 27 86 87