Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 603245 - Review Request: python-zmq - Software library for fast, message-based applications
Review Request: python-zmq - Software library for fast, message-based applica...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Parag AN(पराग)
Fedora Extras Quality Assurance
:
Depends On: 603233
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-11 21:48 EDT by Thomas Spura
Modified: 2011-09-24 11:20 EDT (History)
6 users (show)

See Also:
Fixed In Version: python-zmq-0.1.20100725git18f5d06-3.fc14
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-08-24 17:05:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
panemade: fedora‑review+
limburgher: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Thomas Spura 2010-06-11 21:48:21 EDT
Spec URL: http://tomspur.fedorapeople.org/review/pyzmq.spec
SRPM URL: http://tomspur.fedorapeople.org/review/pyzmq-2.0.7-1.fc13.src.rpm
Description:
The 0MQ lightweight messaging kernel is a library which extends the
standard socket interfaces with features traditionally provided by
specialized messaging middle-ware products. 0MQ sockets provide an
abstraction of asynchronous message queues, multiple messaging
patterns, message filtering (subscriptions), seamless access to
multiple transport protocols and more.

###########################################################################

rpmlint ignorable:
$ rpmlint ./pyzmq-2.0.7-1.fc13.src.rpm x86_64/pyzmq-*
pyzmq.src:63: W: macro-in-comment %{buildroot}
pyzmq.src:63: W: macro-in-comment %{python_sitearch}
pyzmq.src: W: invalid-url Source0: pyzmq-2.0.7.tar.xz
3 packages and 0 specfiles checked; 0 errors, 3 warnings.
(The macro-in-comment warnings help me to remember to look for the %check section.)

koji can't build this atm, because it depends on zeromq, which is currently under review (see blocker list).

###########################################################################

* This package is needed for the next version of ipython.
* I'm unsure about the version number, because in the python egg it's '0.1' but zeromq has version 2.0.7, so I picked 2.0.7 for now and mailed pyzmq's upstream and ask for bumping to the same from zeromq.
Comment 1 Thomas Spura 2010-07-25 09:24:08 EDT
Changes:
- renew git snapshot
- start from version 0.1 like upstream (not the version from zeromq)
- remove buildroot / %%clean

Upstream want to further think about the version naming, because they don't always do version bumps, when a new version of zeromq comes out.
Always having the version number here, which is the required version of zeromq would be the best, but I let that decision to upstream...

_______________________________________________________________________________


rpmlint:
$ rpmlint ./pyzmq-0.1.20100725git18f5d06-1.fc13.src.rpm ./x86_64/pyzmq-*
pyzmq.src: W: no-cleaning-of-buildroot %install
pyzmq.src: W: no-cleaning-of-buildroot %clean
pyzmq.src: W: no-buildroot-tag
pyzmq.src: W: no-%clean-section
pyzmq.src: W: invalid-url Source0: pyzmq-0.1.20100725git18f5d06.tar.xz
3 packages and 0 specfiles checked; 0 errors, 5 warnings.

All of them are false positives.

_______________________________________________________________________________

koji scratch build successful:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2349505

koji scratch build against python 2.7 successful:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2349511

_______________________________________________________________________________


Spec URL: http://tomspur.fedorapeople.org/review/pyzmq.spec
SRPM URL: http://tomspur.fedorapeople.org/review/pyzmq-0.1.20100725git18f5d06-1.fc13.src.rpm
Comment 2 Thomas Spura 2010-07-25 09:33:12 EDT
Hmm, there might be a license issue:

zmq/eventloop/*.py seem to be under apache, but the author says it's LGPLv3+, but I *think* this is allowed to relicense under a more restrictive license, isn't it?

Or should I use this one as License:
LGPLv3+ and ASL 2.0 ?
Comment 3 Parag AN(पराग) 2010-07-27 05:27:48 EDT
1)Python packages installing .so files don't need to follow http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Shared_libraries
so remove that scriptlet from spec.

2) Please don't use more empty lines as I can see between %install and %check

3) also, I see python packaging guidelines now suggests using BR:python2-devel

4) Why do you need following in SPEC?
%global _use_internal_dependency_generator 0
%global __find_provides    %{_rpmconfigdir}/find-provides | grep -v _zmq.so
Comment 4 Parag AN(पराग) 2010-08-02 02:50:41 EDT
spot,
  can you help to determine what will be the license tag for this package?
Comment 5 Tom "spot" Callaway 2010-08-02 09:54:06 EDT
The appropriate license tag should be:

License: LGPLv3+ and ASL 2.0

Lifting FE-Legal.
Comment 6 Thomas Spura 2010-08-03 07:06:07 EDT
(In reply to comment #3)
> 1)Python packages installing .so files don't need to follow
> http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Shared_libraries
> so remove that scriptlet from spec.
Done
> 2) Please don't use more empty lines as I can see between %install and %check
4 empty lines now.
> 3) also, I see python packaging guidelines now suggests using BR:python2-devel
Done
> 4) Why do you need following in SPEC?
> %global _use_internal_dependency_generator 0
> %global __find_provides    %{_rpmconfigdir}/find-provides | grep -v _zmq.so    

Because of bug #619482.

I want to disable the rpm detection of python libs, but till that is done, we need to split them away manually :(
Hopefully, that bug is fixed soon, no python libraries are detected as "Provides".

_________________________________________________________________________________

I now emit a python3- subpackage, so I renamed the program from pyzmq to python-zmq, so it's easier to distinguish between python-* and python3-*.

I needed to remove the example in the python 3 package, because 2to3 won't run on it and crash...

SPEC: http://tomspur.fedorapeople.org/review/python-zmq.spec
SRPM: http://tomspur.fedorapeople.org/review/python-zmq-0.1.20100725git18f5d06-2.fc13.src.rpm
Comment 7 Parag AN(पराग) 2010-08-05 00:46:17 EDT
koji build failed => http://koji.fedoraproject.org/koji/taskinfo?taskID=2380709
Comment 9 Parag AN(पराग) 2010-08-06 05:59:42 EDT
+ koji build => http://koji.fedoraproject.org/koji/taskinfo?taskID=2384449
+ rpmlint output on built package is
 python-zmq.src:139: W: macro-in-comment %{buildroot}
python-zmq.src:139: W: macro-in-comment %{python3_sitearch}
==> If comments are only for temporary then its ok to keep them otherwise remove those lines from spec.
python-zmq.src: W: no-cleaning-of-buildroot %install
python-zmq.src: W: no-cleaning-of-buildroot %clean
python-zmq.src: W: no-buildroot-tag
python-zmq.src: W: no-%clean-section
python-zmq.src: W: invalid-url Source0: pyzmq-0.1.20100725git18f5d06.tar.xz
3 packages and 0 specfiles checked; 0 errors, 7 warnings.
==> Rest of these warnings are ok

- You used everywhere %{buildroot} except one place used $RPM_OPT_FLAGS"
   Please fix this


APPROVED.
Comment 10 Chen Lei 2010-08-09 04:43:30 EDT
IMHO, the name python-zmq don't match Fedora naming guideline, though I think the naming guideline for python modules isn't clearly enough and cause many inconsistencies in the repo.

Currently, many existed py* packages(e.g. pygtk2) are already named as python3-py*. Maybe we should adopt python modules naming guldeine from debian, which seems more clear than ours.
Comment 11 Thomas Spura 2010-08-13 18:52:46 EDT
(In reply to comment #10)
> IMHO, the name python-zmq don't match Fedora naming guideline, though I think
> the naming guideline for python modules isn't clearly enough and cause many
> inconsistencies in the repo.

See: http://fedoraproject.org/wiki/PackageNamingGuidelines#Addon_Packages_.28python_modules.29
"""
[snip]
This makes a package name format of python-$NAME. When in doubt, use the name of the module that you type to import it in a script.
"""

The imported module is zmq -> python-zmq
If it would be pyzmq -> python-pyzmq, but it isn't.
Or what do you mean?

> Currently, many existed py* packages(e.g. pygtk2) are already named as
> python3-py*. Maybe we should adopt python modules naming guldeine from debian,
> which seems more clear than ours.    

Don't know the guidelines from debian... Maybe you could bring that up to the guidelines commitee?
http://lists.fedoraproject.org/pipermail/packaging/

Parag: Thanks for the review. 
       Any doubts to the name "python-zmq"?

(In reply to comment #9)
>  python-zmq.src:139: W: macro-in-comment %{buildroot}
> python-zmq.src:139: W: macro-in-comment %{python3_sitearch}
> ==> If comments are only for temporary then its ok to keep them otherwise
> remove those lines from spec.
This shall remember me for enabling the testsuite as soon as python3-nose is available. So this is partly temarary (don't know when nose will support python3).
> - You used everywhere %{buildroot} except one place used $RPM_OPT_FLAGS"
>    Please fix this
Done locally.
Comment 12 Chen Lei 2010-08-13 23:36:32 EDT
(In reply to comment #11)
> (In reply to comment #10)
> > IMHO, the name python-zmq don't match Fedora naming guideline, though I think
> > the naming guideline for python modules isn't clearly enough and cause many
> > inconsistencies in the repo.
> 
> See:
> http://fedoraproject.org/wiki/PackageNamingGuidelines#Addon_Packages_.28python_modules.29
> """
> [snip]
> This makes a package name format of python-$NAME. When in doubt, use the name
> of the module that you type to import it in a script.
> """
> 
> The imported module is zmq -> python-zmq
> If it would be pyzmq -> python-pyzmq, but it isn't.
> Or what do you mean?
> 
I really like the name python-zmq, however many times when I perform a review, I can't persuade even one submitter to change their package names. They tend to use pyzmq or even python-pyzmq.

Currently, the naming guideline for python modules is ambiguous and already cause a lot of inconsistency in fedora repo.

FYI, currently three naming scheme are used in fedora:
[1]python-[tarball_name] 
Packages of python modules (thus they rely on python as a parent) use a slightly different naming scheme. They should take into account the upstream name of the python module. This makes a package name format of python-$NAME

[2]python-[module_name]
When in doubt, use the name of the module that you type to import it in a script. 

[3]tarball_name
There is an exception to this rule. If the upstream source has "py" (or "Py") in its name, you can use that name for the package. So, for example, pygtk is acceptable. 

Personally, I like most python-modules should use python-[module_name], only a few packages should use python-[tarball_name](e.g. a tarball containing a lot of different namespace or the tarball_name is much more widely used than module_name), tarball_name should be completely forbidden.
Comment 13 Parag AN(पराग) 2010-08-14 00:04:08 EDT
Ok. As per written in http://fedoraproject.org/wiki/PackageNamingGuidelines#Addon_Packages_.28python_modules.29 and upstream is using py in its project name, please change package name to pyzmq.
Comment 14 Parag AN(पराग) 2010-08-14 00:07:58 EDT
also, I am adding Toshio for second opinion here.
Comment 15 Toshio Ernie Kuratomi 2010-08-14 02:05:45 EDT
tomspur is correct here -- The guidelines basically leave it to maintainer option among the listed variants with a preference for python-[module name].  Since there's a python3 version of the module as tomspur notes, python-zmq and python3-zmq makes sense.

pyzmq and python3-pyzmq or  python-pyzmq and python3-pyzmq would also be acceptable combinations but it's maintainer choice among these variants.

Thanks for being thorough.
Comment 16 Parag AN(पराग) 2010-08-14 04:27:47 EDT
Thank you Toshio for your quick reply. So, I think tomspur is free to choose any name as explained above.
Comment 17 Thomas Spura 2010-08-15 07:53:30 EDT
(In reply to comment #16)
> Thank you Toshio for your quick reply. So, I think tomspur is free to choose
> any name as explained above.

Alright, I choose python*-zmq:

New Package SCM Request
=======================
Package Name: python-zmq
Short Description: Software library for fast, message-based applications
Owners: tomspur
Branches: el6 f13 f14
InitialCC:
Comment 18 Kevin Fenzi 2010-08-15 20:11:40 EDT
Git done (by process-git-requests).
Comment 19 Fedora Update System 2010-08-16 07:55:52 EDT
python-zmq-0.1.20100725git18f5d06-3.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/python-zmq-0.1.20100725git18f5d06-3.fc13
Comment 20 Fedora Update System 2010-08-16 07:55:58 EDT
python-zmq-0.1.20100725git18f5d06-3.fc14 has been submitted as an update for Fedora 14.
http://admin.fedoraproject.org/updates/python-zmq-0.1.20100725git18f5d06-3.fc14
Comment 21 Fedora Update System 2010-08-16 12:02:47 EDT
python-zmq-0.1.20100725git18f5d06-3.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update python-zmq'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/python-zmq-0.1.20100725git18f5d06-3.fc14
Comment 22 Fedora Update System 2010-08-24 17:04:58 EDT
python-zmq-0.1.20100725git18f5d06-3.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 23 Fedora Update System 2010-08-24 21:18:04 EDT
python-zmq-0.1.20100725git18f5d06-3.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 24 Thomas Spura 2011-09-21 05:25:29 EDT
Package Change Request
======================
Package Name: python-zmq
New Branches: el5
Owners: tomspur
Comment 25 Gwyn Ciesla 2011-09-24 11:20:44 EDT
Git done (by process-git-requests).

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