Bug 574586 - Review Request: python26-psycopg2 : psycopg2 Postgres client code for python26 on EPEL5
Summary: Review Request: python26-psycopg2 : psycopg2 Postgres client code for python2...
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jason Tibbitts
QA Contact: Fedora Extras Quality Assurance
Depends On: Python26EPEL5
TreeView+ depends on / blocked
Reported: 2010-03-17 21:41 UTC by Dave Malcolm
Modified: 2018-12-21 11:31 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-05-09 18:57:44 UTC
Type: ---

Attachments (Terms of Use)

Description Dave Malcolm 2010-03-17 21:41:11 UTC
Spec URL:


Note: this is purely intended for the EPEL5 branch, not for Fedora

I'm working on a python2.6 stack, parallel-installable with the main 2.4 stack.

This is python-psycopg2-2.0.14-1 from EPEL5 reworked somewhat so that it builds against python2.6, rather than python2.4

Diff versus that specfile:

The rpmlint output is clean, apart from this warning (due to the dist tag):
python26-psycopg2.i386: W: incoherent-version-in-changelog 2.0.14-2 2.0.14-2.el5

The "License" of that package appears to be LGPL version 3 or later, with an exception.  http://fedoraproject.org/wiki/Licensing says "Please be sure that any exceptions are approved by emailing them to fedora-legal-list first."  I haven't done that yet; was this done for python-psycopg2?

The original review request for python-psycopg2 was bug 199784.

Comment 1 Dave Malcolm 2010-03-17 21:44:09 UTC
CCing Devrim GUNDUZ, maintainer of python-psycopg2

Devrim: I'm working on a python2.6 stack for EPEL5, parallel-installable with the main 2.4 stack, and one package I want to maintain is a 2.6 build of psycopg2.  I hope the above looks sane to you.

Comment 2 Devrim Gündüz 2010-03-18 07:54:43 UTC
No problem for me. Please let me know if you need help.

Comment 3 Jason Tibbitts 2010-12-03 18:33:41 UTC
I don't really do anything relating to EPEL, but this has been sitting around for so long and my attempts to get someone to look at it have failed, so I'll take care of it as best I can.

Builds fine in a CentOS5 mock buildroot (no RHEL5 for me; hopefully it doesn't matter).  rpmlint says:
  python26-psycopg2.x86_64: W: private-shared-object-provides
   /usr/lib64/python2.6/site-packages/psycopg2/_psycopg.so _psycopg.so()(64bit)
which were this Fedora I'd say needs to be filtered.  However, the filtering infrastructure doesn't appear to be present in RHEL5

The %pyver macro seems to be defined, but not used.

In Fedora, uses of %define should generally be changed to %global.  (I checked a couple of other python26 reviews and some use %global while yours seem to use %define.  I'm not sure if there's a reason for that.)

You're right, the license tag on the python-psycopg2 package is definitely wrong.  In F13 it's "GPLv2+ with exceptions" which doesn't appear to be correct, and in rawhide it's just "LGPLv3" which is also incorrect.  I just went ahead and fixed it.

I am assuming that you are sticking with 2.0.14 instead of updating to the latest version for reasons relating to the age of RHEL5.  If you wish to package the current instead, just push another package and I'll take a look.

* 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.
* description is OK.
* dist tag is present.
* license field matches the actual license.
* license is open source-compatible.
* license text included in package.
* BuildRequires are proper.
* compiler flags are appropriate.
* package builds in mock (x86_64, EL5).
* package installs properly.
* debuginfo package looks complete.
* rpmlint has acceptable complaints (for EL5, at least).
* final provides and requires are sane:
   python26-psycopg2 = 2.0.14-2.el5

   python26-psycopg2-doc = 2.0.14-2.el5
   python26-psycopg2 = 2.0.14-2.el5

* no bundled libraries.
* no shared libraries are added to the regular linker search paths.
* 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
* code, not content.
* no static libraries.
* no libtool .la files.

Comment 4 Jason Tibbitts 2011-01-20 01:14:17 UTC
Any update here?

Comment 5 GaViT 2011-06-06 15:22:19 UTC
I have been able to download the SRPM from Dave Malcolm. I have edited the SPECFILE to work with postgresql84-server, and have successfully built the RPM.
It seems to have installed well.
I wonder why this hasn't been added to the repos if it "works" so "easily".
For now I think this "solves" my problem.

Comment 6 Adrien Kunysz 2012-01-09 13:05:54 UTC
It seems that spec file cannot be processed properly when python26 is not installed:

$ rpmbuild -bp SPECS/python26-psycopg2.spec                                  
sh: /usr/bin/python2.6: No such file or directory
error: Macro %pyver has empty body
sh: /usr/bin/python2.6: No such file or directory
sh: /usr/bin/python2.6: No such file or directory
sh: /usr/bin/python2.6: No such file or directory
sh: /usr/bin/python2.6: No such file or directory
sh: /usr/bin/python2.6: No such file or directory
sh: /usr/bin/python2.6: No such file or directory
sh: /usr/bin/python2.6: No such file or directory
error: Failed build dependencies:
        python26-devel is needed by python26-psycopg2-2.0.14-2.x86_64
        postgresql-devel is needed by python26-psycopg2-2.0.14-2.x86_64

The "error: Failed build dependencies" is expected but as far as I can tell, the
 "sh: /usr/bin/python2.6: No such file or directory" and "error: Macro %pyver has empty body" should not happen.

Otherwise it seems to work fine.

Comment 7 Jason Tibbitts 2012-05-09 18:57:44 UTC
This has been sitting so long with no progress that I'm just going to close it out.  Since I've already done the review I should be able to finish it up pretty quickly if Dave wants to reopen.

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