Spec URL: https://mpaladin.web.cern.ch/mpaladin/rpms/python-messaging/python-messaging.spec SRPM URL: https://mpaladin.web.cern.ch/mpaladin/rpms/python-messaging/python-messaging-0.5-1.fc16.src.rpm Description: This module provides an abstraction of a "message", as used in messaging, see for instance: http://en.wikipedia.org/wiki/Enterprise_messaging_system. The python module messaging is compatible with the Perl module Messaging::Message.
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.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.