Red Hat Bugzilla – Bug 166506
Review Request: python-basemap - basemap toolkit for matplotlib
Last modified: 2007-11-30 17:11:12 EST
Spec Name or Url: http://www.cora.nwra.com/~orion/fedora/python-basemap.spec
SRPM Name or Url: http://www.cora.nwra.com/~orion/fedora/python-basemap-
Basemap is a matplotlib toolkit that allows you to plot data on map
projections (with continental and political boundaries)
Orion, are youworking on the latest version of python-basemap?
0.6 is out and I intend to review the package.
+ the package builds in mock/x86_64
These can be ignored.
+ package name follows the guideline
+ package follows packaging guidelines
+ license is valid and included in %doc/README
+ spec file is legible and is written in American English
+ source matches upstream
+ Requires and BR OK
+ files ownership OK
Needs work (license related)
- the license seems to me to be BSD like
the Python Software Foundation License is described here:
the license of the package is here:
In case of doubt you could contact its author...
- You need to include LICENSE_proj4 in %doc
If you fix these problems the package is Approved.
I've packaged up 0.6.2. spec and src.rpm in the same location.
I've sent an email to Jeff about the license.
I'm not packaging proj4, just the python wrapper so I don't think I need
Is there any new development here?
If you want to I can contact Jeff about the license.
(In reply to comment #4)
> Is there any new development here?
> If you want to I can contact Jeff about the license.
That might be helpful, I emailed him and got no response.
On a second look, the license is:
copyright (c) 2004 by Jeffrey Whitaker.
Permission to use, copy, modify, and distribute this software and its
documentation for any purpose and without fee is hereby granted,
provided that the above copyright notices appear in all copies and that
both the copyright notices and this permission notice appear in
In PKG-INFO this description shows:
License: OSI Approved
Searching in OSI the best match seems to be:
Since this was the latest problem the package is approved.
Can you take a look at the latest, now split into a -data package as well?
Could you please open another entry for python-basemap-data?
In the patch that you apply to python-basemap I see this:
+# Always build pyshapelib for RPM consistency, uses system shapelib
After this will be build in a safe environment so no problem, OTHO maybe it
could be interesting to package pyshapelib by itself, no?
Is this the only place where it is used?
I saw a message from Jeff in the matplotlib list
where he says that he rewrote some part that required one of the versions
of array (either Numeric or num) in python thus creating pyshapelib.
(In reply to comment #8)
> Could you please open another entry for python-basemap-data?
> In the patch that you apply to python-basemap I see this:
> +# Always build pyshapelib for RPM consistency, uses system shapelib
> After this will be build in a safe environment so no problem, OTHO maybe it
> could be interesting to package pyshapelib by itself, no?
> Is this the only place where it is used?
> I saw a message from Jeff in the matplotlib list
> where he says that he rewrote some part that required one of the versions
> of array (either Numeric or num) in python thus creating pyshapelib.
Two issues here:
- If I build the package on my system and python-basemap is already installed it
won't build the pyshapelib extensions resulting in failure or a bad
(inconsistent) rpm. Since I don't always build in mock, I patched setup.py to
always build it.
- I'm using the system shapelib because I think it is *bad* for packages to
provide their own copies of libraries that are already provided elsewhere. I
don't think it's worth packaging pyshapelib separately at the moment, but we may
wan't to split if someone else want's it. Biggest issue is that I'm not sure
there is really an *official* pyshapelib anywhere.
(In reply to comment #9)
> Two issues here:
> - If I build the package on my system and python-basemap is already installed it
> won't build the pyshapelib extensions resulting in failure or a bad
> (inconsistent) rpm. Since I don't always build in mock, I patched setup.py to
> always build it.
And that is the right thing to do - many people (well, some anyway) rebuild a
src.rpm on their system with a minor tweak - I don't know if this rpm would be
rebuilt by any users, but it could be. rpm's should build on a users system,
even if the same version is already installed.
Are there any outstanding issues here, or can this and the data package be approved?
No outstanding issues. I am sorry I have planned to review this before but
real life got in the way.
I am running now a test that will complete the formal review. Expect it soon.
Review for release 1:
* RPM name is OK
* Spec name is OK
* Source basemap-0.7.2.1.tar.gz is the same as upstream
* Builds fine in mock in x86_64
* rpmlint of python-basemap looks OK
* File list of python-basemap looks OK
* License is OK (GPL)
* Spec file is readable, it is written in American English and it follows
* BR are OK
Checked in and built on devel.
Added to owners.list.
Thanks for the review!