Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at
Bug 165952 - Review Request: libsx. Simple X library
Summary: Review Request: libsx. Simple X library
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Ed Hill
QA Contact: David Lawrence
Depends On:
Blocks: FE-ACCEPT 165955
TreeView+ depends on / blocked
Reported: 2005-08-15 09:47 UTC by Patrice Dumas
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-08-29 21:11:29 UTC
Type: ---

Attachments (Terms of Use)

Description Patrice Dumas 2005-08-15 09:47:43 UTC
SRPM Name or Url:

Libsx (the Simple X library) is a library of code that sits on top of and
to the side of the Athena widget set.  Its purpose is to make writing X
applications *much* easier.

Comment 1 Patrice Dumas 2005-08-15 09:51:41 UTC
I cannot reach the upstream source anymore. I think I found it from the
freshmeat page: The spec file was borrowed
from monkey rpms:, 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.

Comment 2 Patrice Dumas 2005-08-15 09:52:11 UTC
It is a grads dependency.

Comment 3 Ed Hill 2005-08-16 03:55:57 UTC
Hi Patrice, Since this is a dependency for GrADS I'll add it to my to-do list.

Comment 4 Ralf Corsepius 2005-08-16 04:42:00 UTC
# rpmlint  /users/packman/src/rpms/RPMS/i386/libsx-2.05-2.i386.rpm
E: libsx invalid-soname /usr/lib/
E: libsx shlib-with-non-pic-code /usr/lib/
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.

Comment 5 Patrice Dumas 2005-08-16 12:15:34 UTC
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

Comment 6 Ed Hill 2005-08-17 02:17:12 UTC
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"

Comment 7 Patrice Dumas 2005-08-17 07:34:06 UTC
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.

Comment 8 Ed Hill 2005-08-25 19:26:41 UTC
Hi Patrice, heres a more thorough review:

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

 - 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

Comment 9 Patrice Dumas 2005-08-26 12:09:15 UTC
You are really sure that I should remove the 


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

Comment 10 Ed Hill 2005-08-26 13:55:45 UTC
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.

Comment 11 Patrice Dumas 2005-08-26 19:39:24 UTC
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

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

Note You need to log in before you can comment on or make changes to this bug.