Bug 165952
Summary: | Review Request: libsx. Simple X library | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Patrice Dumas <pertusus> |
Component: | Package Review | Assignee: | Ed Hill <ed> |
Status: | CLOSED NEXTRELEASE | QA Contact: | David Lawrence <dkl> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | fedora-package-review |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://freshmeat.net/projects/libsx/ | ||
Whiteboard: | |||
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: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 163779, 165955 |
Description
Patrice Dumas
2005-08-15 09:47:43 UTC
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. |