Bug 474430 - Review Request: python-uulib - Python interface to RFC 4122 compliant UUID objects
Review Request: python-uulib - Python interface to RFC 4122 compliant UUID ob...
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: 2008-12-03 14:42 EST by Ray Van Dolson
Modified: 2009-02-16 18:44 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-02-16 18:44:36 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
tibbs: fedora‑review+
kevin: fedora‑cvs+

Attachments (Terms of Use)

  None (edit)
Description Ray Van Dolson 2008-12-03 14:42:06 EST
Spec URL: http://rayvd.fedorapeople.org/python-uuid/python-uuid.spec
SRPM URL: http://rayvd.fedorapeople.org/python-uuid/python-uuid-1.30-1.el5.src.rpm
This module provides immutable UUID objects (class UUID) and the functions
uuid1(), uuid3(), uuid4(), uuid5() for generating version 1, 3, 4, and 5
UUIDs as specified in RFC 4122.

This should be the same module included with Python 2.5 and later.
Comment 1 Ray Van Dolson 2008-12-03 14:42:46 EST
This is intended solely for EPEL 4 and 5 as the uuid module is included in Fedora already.
Comment 2 Jason Tibbitts 2008-12-06 19:42:38 EST
It's tough to review this as I don't even have the means to build it properly.  I only know how to build Fedora packages, and I guess it should come as no surprise that it doesn't even build in rawhide as python isn't in the buildroot.  Any way you could provide a built package and perhaps the build log?  Or I guess you could wait for someone who knows how to build EPEL-only packages to review this.
Comment 3 Ray Van Dolson 2008-12-06 21:21:15 EST
Hmm... sure.  I can do that in mock.  Hopefully I didn't miss a procedure for EPEL only packages (didn't see one).

Comment 4 Ray Van Dolson 2008-12-07 01:04:12 EST
FYI, here are the mock results for both EPEL-4 and EPEL-5:


I'll check on epel-list to see how EPEL only packages have been handled in the past as well.
Comment 5 Jason Tibbitts 2008-12-10 16:11:21 EST
Basically, every package must have a devel branch; you should immediately dead.package it upon import to ensure that the package is never branched for any Fedora releases.  I don't know of any EPEL-specific procedure other than that.

I'll note for posterity that the code carries no license, but the README.txt file which comes from the same upstream site specifies one.

rpmlint says:
  python-uuid.i386: E: no-binary
  python-uuid-debuginfo.i386: E: empty-debuginfo-package
The debuginfo package is empty, and I see no calls to the compiler in the build log.  Are you sure this package needs to be arch-specific?  I'm not sure it would even build properly on x86_64; did you try?  (On that platform, python_sitearch and python_sitelib aren't the same, while on i386 they 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.
* description is OK.
* dist tag is present.
* build root is OK.
* license field matches the actual license.
* license is open source-compatible.
* license text not included upstream.
* BuildRequires are proper.
* %clean is present.
* package builds in mock (EPEL5, i386).
X debuginfo package is empty.
X rpmlint has valid complaints.
 final provides and requires are sane:
   python-uuid = 1.30-1.el5
   python >= 2.3
   python(abi) = 2.4

* 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.
* documentation is small, so no -doc subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.
Comment 6 Jason Tibbitts 2009-01-13 18:35:23 EST
Any response?  It's been over a month now.
Comment 7 Ray Van Dolson 2009-01-14 12:46:49 EST
Apologies on the delay.  Vacation and resulting fallout but I'll get on this again today.
Comment 9 Jason Tibbitts 2009-02-07 02:35:58 EST
Unfortunately your comment came after the start of the semester, so I've been a bit busy.  Fortunately I have more time now, so I can finish this up.

Things look good now that this is noarch.  The only remaining issue I see is that you have
  Requires:       python >= 2.3, python < 2.5
However, rpm will automaticaly insert a dependency on
  python(abi) = 2.4

Currently there's no guideline against this, but you might want to check out the following draft, which is working its way through the system: http://fedoraproject.org/wiki/PackagingDrafts/ExplicitRequires

So I'll go ahead and approve this, but I would recommend that you kill that extra Requires: line.

Comment 10 Ray Van Dolson 2009-02-07 11:43:00 EST
Thanks Jason!  RPM adds this implicit requires based on the BuildRequires I'm assuming?  Makes sense and I'll remove the explicit Requires from the final version of the package.

Thanks for your work on this.
Comment 11 Ray Van Dolson 2009-02-07 11:53:00 EST
For posterity's sake, here are the final spec and SRPM:


New Package CVS Request
Package Name: python-uuid
Short Description: Python interface to RFC 4122 compliant UUID objects
Owners: rayvd
Branches: EL-5
Comment 12 Ray Van Dolson 2009-02-08 11:05:20 EST
New Package CVS Request
Package Name: python-uuid
Short Description: Python interface to RFC 4122 compliant UUID objects
Owners: rayvd
Branches: EL-4 EL-5
Comment 13 Kevin Fenzi 2009-02-08 17:00:07 EST
cvs done.

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