In Fedora Infrastructure's fedmsg project [1], we're running into an issue with long-running zeromq pub/sub connections timing out with no way to handle them in application code. We think it is related to the following discussion on the zeromq dev list [2]. There is a patch for zeromq the add keep-alives which could serve as a quick-fix [3]. This could be applied to our zeromq-2.2.0, but carrying patches is no fun. The change has made its way into the next zeromq release, version 3.2 [4]. This would be best, I think. There is a compatibility break between the major versions of zeromq (from 2.2 to 3.2) described in [5]. Accordingly, it probably makes the most sense to create a compat-zeromq3.2 forward compat package. I'd be glad to take this on, although I don't have any experience creating forward compat packages for C libraries. We are using zeromq through the python-zmq interface which, luckily, has had experimental support for zeromq-3.2 since python-zmq-2.1.7 which we already have packaged for both Fedora and EPEL. [1]: http://fedmsg.rtfd.org [2]: http://lists.zeromq.org/pipermail/zeromq-dev/2012-January/015242.html [3]: http://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120122/dfa956ee/attachment.txt [4]: https://github.com/zeromq/libzmq/commit/0c3d9179262ab431b8949b8646eed9a1a1e4a233 [5]: http://www.zeromq.org/docs:3-1-upgrade
I would prefer to just upgrade rawhide to the _released_ version 3.2, but there is only a release candidate since a couple of month... This was (and is) the only reason for me not to play with the new version already. When you want to have a zeromq3.2 forward compat package, you'd also need the same for python-zmq (and possibly other bindings). Here are the dependencies: $ repoquery --whatrequires zeromq --repoid=rawhide airinv-0:0.1.2-5.fc19.i686 airinv-0:0.1.2-5.fc19.x86_64 airrac-0:0.2.3-5.fc19.i686 airrac-0:0.2.3-5.fc19.x86_64 airsched-0:0.1.4-5.fc19.i686 airsched-0:0.1.4-5.fc19.x86_64 groonga-plugin-suggest-0:2.0.5-2.fc19.x86_64 perl-ZeroMQ-0:0.21-3.fc18.x86_64 php-zmq-0:0.6.0-6.20120613git516bd6f.fc18.x86_64 python-zmq-0:2.2.0-5.fc18.x86_64 python3-zmq-0:2.2.0-5.fc18.x86_64 rmol-0:0.25.3-6.fc19.i686 rmol-0:0.25.3-6.fc19.x86_64 sevmgr-0:0.2.0-4.fc19.i686 sevmgr-0:0.2.0-4.fc19.x86_64 simcrs-0:0.1.1-3.fc19.i686 simcrs-0:0.1.1-3.fc19.x86_64 simfqt-0:0.1.3-5.fc19.i686 simfqt-0:0.1.3-5.fc19.x86_64 stdair-0:0.45.1-4.fc19.i686 stdair-0:0.45.1-4.fc19.x86_64 trademgen-0:0.2.2-5.fc19.i686 trademgen-0:0.2.2-5.fc19.x86_64 travelccm-0:0.5.3-4.fc19.i686 travelccm-0:0.5.3-4.fc19.x86_64 zeromq-ada-0:2.1.0-9.24032011git.fc19.i686 zeromq-ada-0:2.1.0-9.24032011git.fc19.x86_64 zeromq-ada-devel-0:2.1.0-9.24032011git.fc19.i686 zeromq-ada-devel-0:2.1.0-9.24032011git.fc19.x86_64 zeromq-devel-0:2.2.0-2.fc18.i686 zeromq-devel-0:2.2.0-2.fc18.x86_64 I *hope* all zeromq can now handle zeromq-3, most airline simulation packages are maintained by Denis Arnaud (so CC'ing him to get a opinion from him about just upgrading). So it seems groonga-plugin-suggest would be the only one left... Denis, are your applications working on zeromq-3 already? Ralph, how about a compat-zeromq2, when updating fails instead of a forward package?
As we just discussed in IRC, bumping zeromq to v3 in rawhide and creating a compat-zeromq2 package if necessary makes sense to me. It is unclear if this is appropriate for EPEL, though. I'll stop by the EPEL meeting next Monday to ask how we find that out. At initial glance, it looks like if it would be okay for Fedora, it would be okay for EPEL too: $ repoquery --whatrequires zeromq --repoid=epel zeromq-0:2.1.9-1.el6.i686 zeromq-0:2.1.9-1.el6.x86_64 airinv-0:0.1.2-1.el6.i686 airinv-0:0.1.2-1.el6.x86_64 airrac-0:0.2.3-1.el6.i686 airrac-0:0.2.3-1.el6.x86_64 airsched-0:0.1.4-1.el6.i686 airsched-0:0.1.4-1.el6.x86_64 php-zmq-0:0.6.0-5.20120613git516bd6f.el6.x86_64 python-zmq-0:2.1.9-3.el6.x86_64 rmol-0:0.25.3-1.el6.i686 rmol-0:0.25.3-1.el6.x86_64 sevmgr-0:0.2.0-1.el6.i686 sevmgr-0:0.2.0-1.el6.x86_64 simfqt-0:0.1.3-1.el6.i686 simfqt-0:0.1.3-1.el6.x86_64 stdair-0:0.45.0-1.el6.i686 stdair-0:0.45.0-1.el6.x86_64 trademgen-0:0.2.2-2.el6.i686 trademgen-0:0.2.2-2.el6.x86_64 travelccm-0:0.5.3-1.el6.i686 travelccm-0:0.5.3-1.el6.x86_64 zeromq-0:2.1.9-1.el6.i686 zeromq-0:2.1.9-1.el6.x86_64 zeromq-devel-0:2.1.9-1.el6.i686 zeromq-devel-0:2.1.9-1.el6.x86_64
(In reply to comment #1) > Here are the dependencies: > $ repoquery --whatrequires zeromq --repoid=rawhide > airinv, airrac, airsched, rmol, sevmgr,simcrs, simfqt, stdair, trademgen, travelccm > > I *hope* all zeromq can now handle zeromq-3, most airline simulation > packages are maintained by Denis Arnaud (so CC'ing him to get a opinion from > him about just upgrading). Denis, are your applications working on zeromq-3 already? > Thanks Tom for the upgrade attempt! Yes, all my (simulation-related) packages will be ready for the upgrade (no worry to have on my side). Do not hesitate to proceed, then :)
As discussed again in IRC, we will stay on zeromq version 2 for the zeromq package, and a zeromq3 package will be available in zeromq3. See bug #864937 When all applications are ported, the zeromq package will die and that's it :) Based on how backward compatible upstream currently is, I expect quite a few zeromqX packages in the future, so let's move on that train. I think this will be better for EPEL and not all those compat-zeromqX packages and incompatible changes everywhere...
The "compat" package is now named zeromq3. Closing as a duplicate of the review request. *** This bug has been marked as a duplicate of bug 864937 ***