Bug 491545

Summary: Review Request: pynac - A modified version of GiNaC using Python
Product: [Fedora] Fedora Reporter: Conrad Meyer <cse.cem+redhatbugz>
Component: Package ReviewAssignee: Jason Tibbitts <tibbs>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: fedora-package-review, notting, tomspur
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-10-14 15:22:10 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Conrad Meyer 2009-03-22 17:04:28 EDT
Spec URL: http://konradm.fedorapeople.org/fedora/SPECS/pynac.spec
SRPM URL: http://konradm.fedorapeople.org/fedora/SRPMS/pynac-0.1.3-1.fc10.src.rpm
A modified version of GiNaC that replaces the dependency on CLN by Python.

Rpmlint output:
pynac-devel.x86_64: W: no-documentation
pynac-static.x86_64: W: no-documentation
5 packages and 1 specfiles checked; 0 errors, 2 warnings.

Which are ignorable.

Builds in Koji:
Comment 1 Jason Tibbitts 2009-04-01 12:00:07 EDT
Note that I see 89 additional rpmlint complaints of the type:

pynac.x86_64: W: undefined-non-weak-symbol /usr/lib64/libpynac-0.1.so.2.0.1 

It looks like libpynac isn't linked properly against... something. Maybe libpython?  I guess they assume that everything which will use this library will link against libpython itself, as the .pc file indicates.  I've always thought that to be bad form, but such things aren't review blockers.  Still, do note that you get more rpmlint output if you run it against the installed packages.

It would be nice if %description had some indication of what GiNaC is.  Maybe:
  A modified version of the GiNaC symbolic computation library which uses python 
  as its numerical library.
or something.

Shouldn't the resulting package have some dependency on python or some python library?  I guess that's due to the same issue as the undefined-non-weak-symbol rpmlint complaints; since nothing here is actually linked against libpython, rpm won't find a dependency.  I guess anything built with this package will end up having the proper dependency (if it's built correctly, that is), so I'm really not sure what the proper dependencies are.

* source files match upstream.  sha256sum:
* package meets naming and versioning guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
* summary is OK.
x description is a bit confusing.
* dist tag is present.
* build root is OK.
* license field matches the actual license.
* license is open source-compatible.
* license text included in package.
* latest version is being packaged.
* BuildRequires are proper.
* compiler flags are appropriate.
* %clean is present.
* package builds in mock (rawhide, x86_64).
* package installs properly.
* debuginfo package looks complete.
* rpmlint has acceptable complaints.
? final provides and requires:
   pynac = 0.1.3-1.fc11
   pynac(x86-64) = 0.1.3-1.fc11
  (no python dependency)

   pynac-devel = 0.1.3-1.fc11
   pynac-devel(x86-64) = 0.1.3-1.fc11
   pynac = 0.1.3-1.fc11

   pynac-static = 0.1.3-1.fc11
   pynac-static(x86-64) = 0.1.3-1.fc11
   pynac-devel = 0.1.3-1.fc11

* shared libraries installed:
  ldconfig is called properly.
  unversioned .so link is in the -devel package.
* owns the directories it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
* file permissions are appropriate.
* no generically named files
* scriptlets are OK (ldconfig).
* code, not content.
* documentation is small, so no -doc subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.
* headers are in the -devel package.
* pkgconfig files are in the -devel package; pkgconfig dependency is there.
* static libraries present in a separate -static package.
* no libtool .la files.
Comment 2 Conrad Meyer 2009-04-01 12:16:07 EDT
Yes, this should link against libpython, and then rpm will autogenerate the correct Requires. I will fix the description and try to fix the build process to link against libpython.
Comment 3 Jason Tibbitts 2009-06-20 11:51:21 EDT
So it's been a couple of months; did you intend to provide a new package or should I just close this out?
Comment 4 Conrad Meyer 2009-06-22 21:35:25 EDT
I don't have anything right now; if I get it working, would it be alright to re-open this review?
Comment 5 Jason Tibbitts 2009-06-23 14:22:54 EDT
I don't see why not.  I've already done most of the review work, so if you want to close this and reopen it later, it shouldn't be a problem.  However, I don't see that this package has far to go.

Really, the undefined-non-weak-symbol complaints are not so problematic that they'd block this review; this wouldn't be the first package with somewhat bizarre linking requirements.

The other stuff shouldn't be a big deal.  The python dependency issue might not even be an issue.  I'd just like to see some progress being made on the sage packages.
Comment 6 Conrad Meyer 2009-08-23 18:18:14 EDT
Ok, closing unless someone gets time to work on this (I don't).
Comment 7 Thomas Spura 2009-10-11 10:54:14 EDT
I'd liked to work on this (unless Conrad stepps in and says 'hi' ;))

There is a new version upstream, so I first bumped the release, but now there aren't much rpmlint output:

$ rpmlint pynac.spec ../SRPMS/pynac-0.1.9-1.fc11.src.rpm ../RPMS/x86_64/pynac-*
pynac-devel.x86_64: W: no-documentation
pynac-static.x86_64: W: no-documentation
5 packages and 1 specfiles checked; 0 errors, 2 warnings.

Is there still something to do, I missed?

SPEC: http://student.physik.uni-mainz.de/~spurath/fedora/pynac.spec
SRPM: http://student.physik.uni-mainz.de/~spurath/fedora/pynac-0.1.9-1.fc11.src.rpm
Comment 8 Jason Tibbitts 2009-10-14 15:22:10 EDT
You should open your own review request, and close this one as a duplicate.
Comment 9 Thomas Spura 2009-10-15 09:13:18 EDT

*** This bug has been marked as a duplicate of bug 529198 ***