Re: XFree86 22.214.171.124a-8pre9v6 at master.debian.org/~branden/xfree86
Anders Hammarquist <email@example.com> 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-126.96.36.199a-8pre9v1/debian/rules xfree86-188.8.131.52a/debian/rules
--- xfree86-184.108.40.206a-8pre9v1/debian/rules Tue Dec 29 15:35:58 1998
+++ xfree86-220.127.116.11a/debian/rules Mon Dec 28 22:09:18 1998
@@ -8,7 +8,7 @@
# if your arch needs glibc1 compat support build, add it to this list
+COMPAT_ARCHS=i486 m68k sparc
A:=$(shell dpkg --print-gnu-build-architecture)
ifneq (,$(findstring $(A), $(COMPAT_ARCHS)))
@@ -43,6 +43,7 @@
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
> > 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:
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-18.104.22.168a-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. 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).
As I said above, xserver-vga16 doesn't work - thats the biggest
problem. I think Jakub is going to work on this. Anyways, there is
such a small set of hardware on the Sparc that a simple shell dialog
would probably do the trick.
Jakub Jelinek is using a modified RedHat's Xconfigurator program in
UltraPenguin (which needs more work).