Bug 491545 - Review Request: pynac - A modified version of GiNaC using Python
Review Request: pynac - A modified version of GiNaC using Python
Status: CLOSED DUPLICATE of bug 529198
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Tibbitts
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-03-22 17:04 EDT by Conrad Meyer
Modified: 2009-10-15 09:13 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-10-14 15:22:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
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 ***

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