Bug 491545 - Review Request: pynac - A modified version of GiNaC using Python
Summary: Review Request: pynac - A modified version of GiNaC using Python
Keywords:
Status: CLOSED DUPLICATE of bug 529198
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jason Tibbitts
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-03-22 21:04 UTC by Conrad Meyer
Modified: 2009-10-15 13:13 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-10-14 19:22:10 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Conrad Meyer 2009-03-22 21:04:28 UTC
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
Description:
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:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1253354

Comment 1 Jason Tibbitts 2009-04-01 16:00:07 UTC
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 
  PyTuple_Type

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:
   c7c7538c6dc0da801bb7af6fbbeb1b65800f1a410842416882d02b7bc2381566  
   pynac-0.1.3.spkg
* 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.x86_64.rpm
   libpynac-0.1.so.2()(64bit)
   pynac = 0.1.3-1.fc11
   pynac(x86-64) = 0.1.3-1.fc11
  =
   /sbin/ldconfig
   libgcc_s.so.1()(64bit)
   libgcc_s.so.1(GCC_3.0)(64bit)
   libpynac-0.1.so.2()(64bit)
   libstdc++.so.6()(64bit)
   libstdc++.so.6(CXXABI_1.3)(64bit)
   libstdc++.so.6(CXXABI_1.3.1)(64bit)
   libstdc++.so.6(GLIBCXX_3.4)(64bit)
   libstdc++.so.6(GLIBCXX_3.4.11)(64bit)
   libstdc++.so.6(GLIBCXX_3.4.5)(64bit)
   libstdc++.so.6(GLIBCXX_3.4.9)(64bit)
  (no python dependency)

  pynac-devel-0.1.3-1.fc11.x86_64.rpm
   pynac-devel = 0.1.3-1.fc11
   pynac-devel(x86-64) = 0.1.3-1.fc11
  =
   /usr/bin/pkg-config
   libpynac-0.1.so.2()(64bit)
   pkgconfig
   pynac = 0.1.3-1.fc11

  pynac-static-0.1.3-1.fc11.x86_64.rpm
   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 16:16:07 UTC
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 15:51:21 UTC
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-23 01:35:25 UTC
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 18:22:54 UTC
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 22:18:14 UTC
Ok, closing unless someone gets time to work on this (I don't).

Comment 7 Thomas Spura 2009-10-11 14:54:14 UTC
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 19:22:10 UTC
You should open your own review request, and close this one as a duplicate.

Comment 9 Thomas Spura 2009-10-15 13:13:18 UTC

*** 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.