Bug 784603

Since i'm not a sponsor, i will just do an informal review:
* if you don't plan to support EPEL5, remove any reference to BuildRoot cleaning and %defattr
* Summary is not very informative (ie: Messaging abstraction for Python)
* according PyPI, messaging does support python3, so you should provide a python3 variant (if it's supported upstream, as a reviewer, i consider this is a blocker)
* rpmlint is surprisingly silent (not even a single false positive spelling error !)
* builds fine inside mock
* provided sources checksum match with upstream's
* license is OK (Apache 2.0)

Except for the python3 variant, it complies with Fedora packaging guidelines. I recommend as a wannabe fedora packager, that you start doing informal reviews to show your future sponsor, that you have a well-understanding of our guidelines and help other reviews to advance.

Thank you very much for the informal review, very useful!
* I need to push the package to EPEL5 too, do I need to provide a python26 variant as well?
* is the summary 'Python abstraction of a "message"' fine? perl-Messaging-Message has the same summary
* I added a python3 variant following http://fedoraproject.org/wiki/Packaging:Python
* rpmlint is still silent
* it builds in mock
* sources checksum should have not been changed
* license is still the same

Thanks for the recommendations!

* python26-xxx variants in EPEL5 are different packages, you'd need to submit another review
http://koji.fedoraproject.org/koji/search?match=glob&type=package&terms=python26*
https://bugzilla.redhat.com/show_bug.cgi?id=782613 (an example of python26 variant ticket)
* for the summary, it's better than the previous one.
* python3 variant builds fine and is usable.

To me, your package fully complies with Fedora guidelines, you still have to be formally reviewed by a sponsor (which usually will ask you to do 2 or 3 informal reviews), try asking on irc (#fedora-devel @ freenode) or the mailing list.

It's up to you if you want to do a python26 package on EPEL5 and also a python3 package on Fedora as well for that matter.

There is no need to do a separate package for these and recommend to you don't in fact.

As mentioned in #784613 you must do some informal reviews and provide a link to them here.

Otherwise I am happy to sponsor you.
Steve

One first informal review:
https://bugzilla.redhat.com/show_bug.cgi?id=788080

Steve,

here is another informal review on a globus package (I haven't found anything bad):
https://bugzilla.redhat.com/show_bug.cgi?id=772994

Steve,

here is another informal review:
https://bugzilla.redhat.com/show_bug.cgi?id=790215

Steve,

another globus package informal review:
https://bugzilla.redhat.com/show_bug.cgi?id=772986

Thanks, I'll go through all this in the next few days.

Steve.

Package Review
==============

Key:
- = N/A
x = Pass
! = Fail
? = Not evaluated



==== Generic ====
[x]: MUST Package is licensed with an open-source compatible license and meets
     other legal requirements as defined in the legal section of Packaging
     Guidelines.
ASL 2.0
[x]: MUST Package successfully compiles and builds into binary rpms on at
     least one supported primary architecture.
[x]: MUST All build dependencies are listed in BuildRequires, except for any
     that are listed in the exceptions section of Packaging Guidelines.
[x]: MUST Buildroot is not present
     Note: Buildroot is not needed unless packager plans to package for EPEL5
EPEL5 targeted.
[x]: MUST Package contains no bundled libraries.
[x]: MUST Changelog in prescribed format.
[x]: MUST Package has no %clean section with rm -rf %{buildroot} (or
     $RPM_BUILD_ROOT)
     Note: Clean would be needed if support for EPEL is required
EPEL5 so yes.
[x]: MUST Sources contain only permissible code or content.
[x]: MUST Each %files section contains %defattr if rpm < 4.4
     Note: defattr(....) present in %files section. This is OK if packaging
     for EPEL5. Otherwise not needed
[x]: MUST Macros in Summary, %description expandable at SRPM build time.
[x]: MUST Package requires other packages for directories it uses.
[x]: MUST Package uses nothing in %doc for runtime.
[x]: MUST Permissions on files are set properly.
[x]: MUST Package does not contain duplicates in %files.
[x]: MUST Spec file lacks Packager, Vendor, PreReq tags.
[x]: MUST Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
     beginning of %install.
     Note: rm -rf would be needed if support for EPEL5 is required
[x]: MUST If (and only if) the source package includes the text of the
     license(s) in its own file, then that file, containing the text of the
     license(s) for the package is included in %doc.
[x]: MUST License field in the package spec file matches the actual license.
[x]: MUST License file installed when any subpackage combination is installed.
[x]: MUST Package consistently uses macros (instead of hard-coded directory
     names).
[x]: MUST Package meets the Packaging Guidelines.
[x]: MUST Package is named according to the Package Naming Guidelines.
[x]: MUST Package does not generates any conflict.
[x]: MUST Package obeys FHS, except libexecdir and /usr/target.
[x]: MUST Package must own all directories that it creates.
[x]: MUST Package does not own files or directories owned by other packages.
[x]: MUST Package installs properly.
[x]: MUST Requires correct, justified where necessary.
[x]: MUST Rpmlint output is silent.

rpmlint python-messaging-0.5-1.fc18.noarch.rpm

1 packages and 0 specfiles checked; 0 errors, 0 warnings.


rpmlint python-messaging-0.5-1.fc18.src.rpm

1 packages and 0 specfiles checked; 0 errors, 0 warnings.

rpmlint python3-messaging-0.5-1.fc18.noarch.rpm

1 packages and 0 specfiles checked; 0 errors, 0 warnings.


[x]: MUST Sources used to build the package match the upstream source, as
     provided in the spec URL.
/home/steve/reviews/784603/messaging-0.5.tar.gz :
  MD5SUM this package     : 0b41ba68ef9951c862c73bdcc0917694
  MD5SUM upstream package : 0b41ba68ef9951c862c73bdcc0917694

[x]: MUST Spec file is legible and written in American English.
[x]: MUST Spec file name must match the spec package %{name}, in the format
     %{name}.spec.
[x]: MUST Package contains a SysV-style init script if in need of one.
[x]: MUST File names are valid UTF-8.
[x]: SHOULD Reviewer should test that the package builds in mock.
[x]: SHOULD If the source package does not include license text(s) as a
     separate file from upstream, the packager SHOULD query upstream to
     include it.
[x]: SHOULD Dist tag is present.
[x]: SHOULD No file requires outside of /etc, /bin, /sbin, /usr/bin,
     /usr/sbin.
[x]: SHOULD Final provides and requires are sane (rpm -q --provides and rpm -q
     --requires).
[x]: SHOULD Package functions as described.
[x]: SHOULD SourceX is a working URL.
[?]: SHOULD %check is present and all tests pass.
[ ]: SHOULD Packages should try to preserve timestamps of original installed
     files.
[x]: SHOULD Spec use %global instead of %define.

Issues:

Generated by fedora-review 0.1.2
External plugins:

My Comments: 
(1)
I don't quite understand the logic here:
%if ! (0%{?with_python3})
BuildRequires:  python-simplejson
Requires:       python-simplejson
%endif # if ! with_python3

This says that on platforms where python3 is not availble then install
install python-simplejson. But e.g rhel6 and fedora15 both have python 2.6
but only fedora15 has python3.

I would probably use a dist tag for this since it's the default python
version per distribution that is relevent.

On a similar not I would have two %if , %end statements instead of

%if 0%{?fedora} > 12 || 0%{?rhel} > 6
%global with_python3 1
%else
%{!?python_sitelib: %global python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print (get_python_lib())")}
%endif

you are mixing the fact that  python3 landing happen to coincide with rpm setting python_sitelib automatically. They are not related even if they happened at the same time.

%python_sitelib is only not set for EPEL5 these days.


(2)
Referencing a URL in the description? Why not just add the relevent
text to the description.

(3)
This noarch package with no compilation. i.e 
CFLAGS="$RPM_OPT_FLAGS" is waste of space.

(4)
Building on fedora18 this is fine.

$ rpm -qp --requires python-messaging-0.5-1.fc18.noarch.rpm 
python(abi) = 2.7

I think it is still the case that on EPEL5 this is not auto-generated
so you must add this requires explicitly for epel5 only.

Steve.

Steve,

some comments/questions before making the changes.

(1) I am gonna change python-simplejson dependency, it is required only for python < 2.6
 
This if:
%if 0%{?fedora} > 12 || 0%{?rhel} > 6
%global with_python3 1
%else
%{!?python_sitelib: %global python_sitelib %(%{__python} -c "from
distutils.sysconfig import get_python_lib; print (get_python_lib())")}
%endif
is coming from http://fedoraproject.org/wiki/Packaging:Python , may be that should be changed.

(2) URL was coming from a copy & paste of the README file, will change that

(3) again, this appears in http://fedoraproject.org/wiki/Packaging:Python , shall it be mentioned in that page?

(4) with mock and EPEL5 looks fine so I don't think it needs to be changed, right?
$ rpm -qp --requires /var/lib/mock/epel-5-x86_64/result/python-messaging-0.5-1.el5.centos.noarch.rpm 
python(abi) = 2.4

Steve,

package updated:
https://mpaladin.web.cern.ch/mpaladin/rpms/python-messaging/python-messaging.spec
https://mpaladin.web.cern.ch/mpaladin/rpms/python-messaging/python-messaging-0.5-2.fc16.src.rpm

Approved , you should be able to procede with an scm request next.

New Package SCM Request
=======================
Package Name: python-messaging
Short Description: Python abstraction of a "message", as used in Enterprise Messaging
Owners: mpaladin
Branches: f16 f17 el5 el6
InitialCC:

Git done (by process-git-requests).

python-messaging-0.5-2.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/python-messaging-0.5-2.fc17

python-messaging-0.5-2.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/python-messaging-0.5-2.fc16

python-messaging-0.5-2.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/python-messaging-0.5-2.el6

python-messaging-0.5-2.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/python-messaging-0.5-2.el5

python-messaging-0.5-2.fc17 has been pushed to the Fedora 17 testing repository.

python-messaging-0.5-2.fc16 has been pushed to the Fedora 16 stable repository.

python-messaging-0.5-2.fc16 has been pushed to the Fedora 16 stable repository.

python-messaging-0.5-2.fc17 has been pushed to the Fedora 17 stable repository.

python-messaging-0.5-2.el6 has been pushed to the Fedora EPEL 6 stable repository.

python-messaging-0.5-2.el5 has been pushed to the Fedora EPEL 5 stable repository.

Package Change Request
======================
Package Name: python-messaging
New Branches: epel7
Owners: stevetraylen

Branch exists.