I cannot reach the upstream source anymore. I think I found it from the
freshmeat page: http://freshmeat.net/projects/libsx/. The spec file was borrowed
from monkey rpms: http://monkeyrpms.net/fc2-i386/html/libsx.html, which has
version 2.04. A diff between the 2.05 included in my srpm and the monkey rpm
2.04 shows very few differences, almost only version strings.

It is a grads dependency.

Hi Patrice, Since this is a dependency for GrADS I'll add it to my to-do list.

# rpmlint  /users/packman/src/rpms/RPMS/i386/libsx-2.05-2.i386.rpm
E: libsx invalid-soname /usr/lib/libsx.so libsx.so
E: libsx shlib-with-non-pic-code /usr/lib/libsx.so
W: libsx devel-file-in-non-devel-package /usr/include/libsx.h
W: libsx devel-file-in-non-devel-package /usr/include/freq.h
W: libsx devel-file-in-non-devel-package /usr/lib/libsx.a
W: libsx devel-file-in-non-devel-package /usr/lib/libfreq.a

IMO, in this case, rpmlint is right and all of them should be considered blockers.

Also, freq.h probably is an internal header, which should not be shipped.

The freq.h is indeed an internal header and libfreq.a also shouldn't be shipped.
I made a new package that don't ship them anymore. I also added mkinstalldirs to
have it build in mock. And I also added some doc and fixed the old freq example
to have an example of use of GetFile. I fixed the shared libs issues and split
the package in devel and non devel. Here is the rpm changelog entry:

- don't ship freq.h or libfreq.a, it is an example
- add a simpler definition of SimpleGetFile in freq
- ship the example dirs and the doc
- use and ship mkinstalldirs to create the dirs instead of mkdirhier
- handle correctly shared libraries


The new package is at

http://www.environnement.ens.fr/docs/fc-srpms/libsx-2.05-3.src.rpm

Hi Patrice, I tried the -3 version and now rpmlint does not complain 
about the main package (which is good) but it does give 16 
dangling-relative-symlink warnings such as:

  W: libsx-devel dangling-relative-symlink
     /usr/share/doc/libsx-devel-2.05/xmore/libsx.h ../src/libsx.h

and one error:

  E: libsx-devel wrong-script-interpreter
     /usr/share/doc/libsx-devel-2.05/pcurve/makefile "smake"

I fixed the dangling symlinks by removing the files. The error seems doubly
wrong to me: the makefile is not executable and smake may be a valid
interpreter. Should I really fix it?

I know that some of the examples won't build as is but I don't think this is
something we should bother with.

Hi Patrice, heres a more thorough review:

needswork:
 - please see rpmlint errors above (comment #6)
 - please use:  Requires: %{name} = %{version}-%{release}
   instead of:  Requires: %{name} = %{version}

good:
 - source matches upstream
 - appears to satisfy all the Guidelines
 - license is OK and included
 - spec looks good
 - builds in mock on FC-4
 - ldconfig looks OK
 - dir ownership OK
 - permissions OK
 - clean OK
 - code not content
 - proper use of -devel sub-package

and, overall, it looks good.  So its APPROVED provided you make the above
(small) changes before requesting the first build.  And I'll review GrADS
next.

You are really sure that I should remove the 

#!smake

even if it there is no problem with using smake to rebuild makefiles and the
makefile isn't executable?

I have added for the -devel package:
Requires: xorg-x11-devel

Honestly, I'm not sure.  ;-)

What is "smake", anyway?  I'm not familiar with it and it doesn't seem to be 
included anywhere in Fedora--or is it?

And since it is just an example makefile I suppose it really doesn't matter 
whether you leave it there or not.

It is an alternate system with similar goals than automake. And it is not in
fedora (but in debian). But the point is not there, whatever smake is, having a 

#! smake

at the first line of a non executable makefile is not a packaging error in my
opinion. 

I import the package in the cvs with that rpmlint error.