Re: XFree86 3.3.2.3a-8pre9v6 at master.debian.org/~branden/xfree86
Note to Def
Branden Robinson <branden@ecn.purdue.edu> writes:
> This is what I hope to be the final test build of XFree86 3.3.2.3a-9; if
> there are no significant problems it will be released with that version
> number. This test build addresses all four release-critical bugs currently
> outstanding against XFree86.
> There are exactly 5 things I want to do for -10, and then I will declare
> slink X done (barring any nasty bugs that crop up).
> * have XF86Setup mung /etc/X11/Xserver (and call correct X server during
> test)
> * deal with new font and static library packages in the upgrade department
> * XKB and locale fixes for our non-American friends
> (bugs.debian.org/xlib6g)
> * merge alpha patches
> * merge sparc patches
My sparc patches or the older ones that Anders sent you?
> Alpha and sparc patches need to be i386-safe. I don't know that they
> aren't; I haven't checked closely yet. My next test build will likely
> incorporate the alpha patches and I will want to see if it works okay on
> i386. Almost all of the Alpha patches have to do with 64-bit alignment
> issues, and should not affect the i386. But there's always the chance of
> something lurking...
> If some sparc folks could confirm that their patches are similarly safe for
> i386 consumption I'll subsequently add those. I imagine the Alpha patches
> will make life easier for the sparc64/UltraLinux port (do we have one
> yet?).
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.)
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.
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.
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). 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.
What do the other Debian Sparc people think? Should we update the X
binaries in slink so that we are shipping source code and have
UltraSparc support?
(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
machines.)
Steve
dunham@cse.msu.edu
Reply to: