Red Hat Bugzilla – Bug 508188
Review Request: pywbem - Python WBEM Client and Provider Interface
Last modified: 2009-07-05 22:44:44 EDT
Spec URL: http://ke4qqq.fedorapeople.org/pywbem.spec
SRPM URL: http://ke4qqq.fedorapeople.org/pywbem-0.7.0-1.fc11.src.rpm
Description: A Python library for making CIM operations over HTTP using the WBEM
CIM-XML protocol. It is based on the idea that a good WBEM client should be
easy to use and not necessarily require a large amount of programming
knowledge. It is suitable for a large range of tasks from simply poking
around to writing web and GUI applications.
It also provides a Python provider interface, and is the fastest and
easiest way to write providers on the planet.
This seems to be a duplicate of bug 245688.
So it is, thanks for catching that. I noticed that you inquired on 20 June 2009 regarding the status of that review. Since it is just a few days yet till the week required to mark package review FE-DEADREVIEW under the "Policy for Stalled Package Reviews" I will hold off on making any additional progress till 28 June and review that bug for progress there. If there is no progress I'll mark bug 245688 as FE-DEADREVIEW and proceed here. My preference is for someone else to maintain it (and for a new packager to be added in the process).
*** Bug 245688 has been marked as a duplicate of this bug. ***
I've given up on the other ticket and have closed it. I'll go ahead and take care of this one. Hopefully in the future the legal issue preventing an HP employee from signing the CLA will be resolved and the submitter of that ticket (who is one of the upstream developers) can co-maintain.
As in the other review, I would urge some elaboration of the acronym stew that is the description.
You could drop BuildRequires: python, although it doesn't hurt anything to have it.
Are you sure it's wise to rename the executables? Of course, the other review renamed the executables to mofcomp and pywbemcli, so perhaps there's simply no standard for the names of these executables. Maybe it's worth checking with upstream about this.
twisted_client.py seems to depends on python-twisted; should that be a runtime dependency?
* 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.
* latest version is being packaged.
* BuildRequires are proper (BR: python is unnecessary but not harmful).
* %clean is present.
* package builds in mock (rawhide, x86_64).
* package installs properly.
* rpmlint is silent.
* final provides and requires are sane:
pywbem = 0.7.0-1.fc12
python(abi) = 2.6
* %check is not present; no test suite upstream.
* 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.
> As in the other review, I would urge some elaboration of the acronym stew that
> is the description.
I left the common stuff such as SNMP and HTTP but added acronym expansions for CIM and WBEM, and a brief explanation of WBEM.
> You could drop BuildRequires: python, although it doesn't hurt anything to have
> Are you sure it's wise to rename the executables? Of course, the other review
> renamed the executables to mofcomp and pywbemcli, so perhaps there's simply no
> standard for the names of these executables. Maybe it's worth checking with
> upstream about this.
I renamed the executables per:
That said, the pyc and pyo in question still get generated by setup.py, just not in bin_dir, they remain in python_sitelib. I suppose I could rename the two scripts in question in %prep. But that isn't the bug directly referenced by the packaging guidelines note.
That said, I assume since Tim is at least part of upstream that his naming is ok, and thus I changed mine to reflect what his symlink names were.
> twisted_client.py seems to depends on python-twisted; should that be a runtime
It should be, thanks for catching that. It's added in the next version.
Thanks for the review!
Hmm, note that page on unnecessary byte compilation includes a link to the bug, which you may note was closed back in March. I know the issue was fixed in rawhide; I'm pretty sure that happened before F11 branched, so F11 should have the fix as well.
Note that you picked up a new rpmlint warning:
pywbem.src: W: mixed-use-of-spaces-and-tabs (spaces: line 2, tab: line 13)
which I don't care at all about, but you might.
I suppose you could fix setup.py to install those executables in the proper place for executables, or petition upstream to do so, or do what Tim's package did and just link to them. Or leave things the way you have them; I don't think it makes a significant difference, although the current method has the dangling .pyc and .pyo files with no corresponding .py file which does seem a bit odd.
Otherwise this still builds and installs, and the major issues have been fixed, so I think this is fine.
Thanks for the review.
I'll fix the space/tab issue before the spec hits CVS.
I'll talk to upstream about how they'd like to see the executables handled.
New Package CVS Request
Package Name: pywbem
Short Description: Python WBEM Client and Provider Interface
Branches: F-10 F-11 EL-5
pywbem-0.7.0-2.fc11 has been submitted as an update for Fedora 11.
pywbem-0.7.0-2.fc10 has been submitted as an update for Fedora 10.
pywbem-0.7.0-2.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
pywbem-0.7.0-2.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
Hi everyone. I've just returned from three months leave and seem to have missed all the pywbem excitement. Thanks very much Jason and David for getting this done. I'm not sure what happened to my request to legal - it seems have gotten lost somewhere.
David, I'm happy to take over maintainership if that's still what you want.
As I said earlier, I'd prefer that someone more connected with upstream maintain it. I packaged it because I had a need for pywbem in EPEL at $dayjob.
Once you get the CLA squared away and get the packager sponsorship taken care of, please let me know, I'll be happy to pass this off to you.