It does not compile in mock, from build.log:

In file included from spp.cpp:16:
spp.h:19:30: error: readline/history.h: No such file or directory
spp.cpp: In constructor 'SPPParse::SPPParse()':
spp.cpp:27: error: 'using_history' was not declared in this scope
make[2]: *** [spp.o] Error 1
make[2]: Leaving directory `/builddir/build/BUILD/sax/spp'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/builddir/build/BUILD/sax/spp'
make: *** [all] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.78460 (%build)

yes readline is required. I added the package to the BuildRequires.
If you don't mind try again:

   ftp://ftp.berlios.de/pub/sax/review/sax2-8.1-70.src.rpm

I was able to build it on my test machine with FC5 installed. Packages
can be found on berlios ftp as well. Thanks for your effort I'm hopping
you will be successful the next time


   

Not building, same error. Add readline-devel to BuildRequires.

/usr/share/locale is forbidden, use %find_lang

Use python macros from fedora-rpmdevtools package to avoid hardcoding
site-packages dir.

Require the libX* package instead of the xorg implementation.

Drop the PreReq, not needed. Probably most of Requires too, most of it is
covered from library requirements brought in by BuildRequires.

Why %define __perl_requires %{nil} ? This could use a comment.

Need to use a lot more macros. Ideally, at least in my opinion, there are no
/usr references anywhere in the spec.

There are readability issues with the SuSE specific parts.

BTW, we have no rule for this in the Guidelines, but I think the questions
should be raised: Does it create a valid config for Fedora Core? E.g. are module
path set proberly? Does it load the same modules as the xorg.conf created my
system-config-display?

In other words: Does sax2 really make sense for Fedora Extras or might it do
more harm because it does things in different ways than system-config-display
(which  could lead to problems or bugs in other areas)?

- In reply to comment #3. John, thanks for pointing out the mistakes I made
  in the spec file. I will take care for the mentioned issues.

- But before I continue I think it is more important to discuss comment #4
  Thorsten I can understand your concerns and maybe it makes no sense to have
  more than one X11 config tool an a distribution. I started to make sax
  working on fedora because there were enough questions :) I thought it would
  be a good idea to have that config tool available as an extra package. As
  far as I understand this will give people an option to use it. I really
  don't want to come into conflict with system-config-display and if I did that
  it happens accidently and I'm sorry for that. In this case I have no problems
  to stop my efforts immediately.

  sax touches only the xorg.conf file and creates a valid file which can be
  read in using Xorg's libxf86config. If system-config-display has its own
  library I agree this could lead to a problem when it tries to parse the sax
  written file. I'm using fedora at the University and I'm using sax
  to configure X there. If you want you can give it a try with the packages
  I provide on:

    ftp://ftp.berlios.de/pub/sax/head-build/i386/FC5

  To see how it works it is the best to run sax2 from runlevel 3
  If you think it is not useful, I will stop bothering you guys :)

Thanks
      

I am dropping reviewing this.

The current spec does look a bit tricky to maintain with the SuSE and Fedora
parts. And I would use system-config-display anyway.

If anyone else wants to pick it up go ahead.

Moving back to FE-NEW since this package isn't under review now. 

Marcus, I'm assuming you need to be sponsored. Adding FE-NEEDSPONSOR.

Also there is traditionally strong resistance to accept SPEC files that contain
non-Fedora related bits, so I think you have a much better chance to get this
reviewed with a Fedora-only SPEC file. :-)

Ping Marcus. 
Do you still wish to submit this package? 
If so can you post an updated version? If not, can we close this request?

If I don't hear anything in a week, I will close this request. 

Sorry for the delay. I think we can close this one. With the development
of randr v1.2 and the way to dynamic X configuration it doesn't make much
sense