Re: XFree86 3.3.2.3a-8pre9v6 at master.debian.org/~branden/xfree86
Anders Hammarquist <[EMAIL PROTECTED]> writes: > > 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. And the stuff in the debian dir. I also found that I had to use a hack to remove the -pedantic line from the configuration files to get the altdev stuff to compile: diff -ruN xfree86-3.3.2.3a-8pre9v1/debian/rules xfree86-3.3.2.3a/debian/rules --- xfree86-3.3.2.3a-8pre9v1/debian/rules Tue Dec 29 15:35:58 1998 +++ xfree86-3.3.2.3a/debian/rules Mon Dec 28 22:09:18 1998 @@ -8,7 +8,7 @@ DEBTREEDIR5:=$(shell pwd)/debian/xtree-libc5 # if your arch needs glibc1 compat support build, add it to this list -COMPAT_ARCHS=i486 m68k +COMPAT_ARCHS=i486 m68k sparc A:=$(shell dpkg --print-gnu-build-architecture) ifneq (,$(findstring $(A), $(COMPAT_ARCHS))) @@ -43,6 +43,7 @@ build-old: $(checkdir) mkdir $(L5) && cp -a include config lib Makefile $(L5)/ + perl -pi -e 's/-pedantic//' $(L5)/config/cf/xfree86.cf cp -a debian/Imakefile.l5 $(L5)/Imakefile sed s/@ARCH@/$(A)/ < debian/site.def.l5.in > $(L5)/config/cf/site.def mkdir -p $(L5)/programs/Xserver If it doesn't compile for you, add this hack. I doesn't hurt anything. (The pedantic compiler doesn't like the sparc altdev header files.) > > 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 would assume that these patches will conflict then (because Alpha would do #ifdef __alpha__ and sparc would do #ifdef __sparc__), but they should be easy to fix. > 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 now). A lot of them are the same. My latest patches against Branden's source are at: ftp://www.cse.msu.edu/pub/debian/X/xfree86.sparc.diff.gz There is also a "split.pl" which splits the patch into many files (one per target file). I don't know how helpful it would be, but it's there if you want it. (You can use "cat" and shell globbing to put the pieces back together. In particular, you might want to seperate out the patches to the debian directory.) These patches are against the xfree86-3.3.2.3a-8pre9v1 tree with Brandens patches already applied. > > 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 patches. Ok, the only big issue is that you'll probably have to update your stuff in the Debian directory. Also, to handle my stuff, you will need to add the XF86_Mach64 server to the list of packages generated for the sparc. (There is a XF86_VGA16 server too, but it doesn't seem to work, so I'm not packaging it.) Also, make sure the patch at cfb8line.c:898 gets applied, it's not in RedHat's stuff (my own patch) and fixes a bus error in 16bit mode which is triggered by WindowMaker. > > 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. AFAIK, the sparc stuff hasn't been merged in yet, but it will eventually be merged in. > > (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. A
Re: XFree86 3.3.2.3a-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 now). > 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 patches. > 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 > machines.) 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). Regards, /Anders -- -- Of course I'm crazy, but that doesn't mean I'm wrong. Anders Hammarquist | [EMAIL PROTECTED] Physics student | Hem: +46 31 47 69 27 Chalmers University of Technology, G|teborg, Sweden | Mob: +46 707 27 86 87
Re: XFree86 3.3.2.3a-8pre9v6 at master.debian.org/~branden/xfree86
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]
