Note to Def
Branden Robinson <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
