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

Summary: Review Request: libsx. Simple X library
Product: [Fedora] Fedora Reporter: Patrice Dumas <pertusus>
Component: Package ReviewAssignee: Ed Hill <ed>
Status: CLOSED NEXTRELEASE QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: fedora-package-review
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-08-29 21:11:29 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 163779, 165955    

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.