Hide Forgot
Description of problem: I installed python-celery, but I cannot start celeryd because it has a runtime dependency on python-billiards, ensuring that <3.0 is installed. Version-Release number of selected component (if applicable): $ rpm -qa | grep cel python-celery-3.0.15-3.fc19.noarch $ rpm -qa | grep bill python-billiard-3.3.0.0-1.fc19.x86_64 How reproducible: Very Steps to Reproduce: 1. yum install python-celery 2. celeryd Actual results: $ celeryd Traceback (most recent call last): File "/usr/bin/celeryd", line 5, in <module> from pkg_resources import load_entry_point File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 2809, in <module> parse_requirements(__requires__), Environment() File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 594, in resolve raise DistributionNotFound(req) pkg_resources.DistributionNotFound: billiard>=2.7.3.21,<3.0 Expected results: I would expect celeryd to run. Additional info: I've done some investigative work to determine whether it would be safe to downgrade billiard to a 2.x version. I've looked at the primary.xml data in the F19 and updates repositories, and it seems to be that only askbot and python-celery use billiard. Neither of the RPMs require any particular version of billiard, so it may be possible to downgrade F19 to a 2.x series of billiard (assuming that the RPM data on askbot's requirements is accurate). Of course, the Celery RPM should require <3.0 on the billiard RPM as well. Thanks, and let me know if you need any further information.
Thank you for the report. Billiard was recently upgraded with this build http://koji.fedoraproject.org/koji/buildinfo?buildID=474362 IMHO, this is a violation of the stable policy. https://fedoraproject.org/wiki/Updates_Policy#Stable_Releases and we shouldn't do package upgrades once a Fedora version is released. So. Now that it happened, one could fix this by introducing an epoch, by the cost of never being able to get rid of that again.
Thanks for your comments Matthias. I agree that we should use the epoch field to bring back the 2.7 series of billiard, since there is no other way to resolve this issue that I am aware of. I've also reported #1029067[0] to request that the Celery spec file explicitly require billiard < 3.0 instead of requiring any version of billiard, so as to avoid this problem in the future. Thanks again, and let me know if I can be of any further assistance. [0] https://bugzilla.redhat.com/show_bug.cgi?id=1029067
python-kombu-2.5.16-1.fc20,python-celery-3.0.19-5.fc20,python-billiard-2.7.3.34-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/python-kombu-2.5.16-1.fc20,python-celery-3.0.19-5.fc20,python-billiard-2.7.3.34-1.fc20
python-kombu-2.5.16-1.fc19,python-celery-3.0.15-4.fc19,python-billiard-2.7.3.34-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/python-kombu-2.5.16-1.fc19,python-celery-3.0.15-4.fc19,python-billiard-2.7.3.34-1.fc19
Package python-kombu-2.5.16-1.fc20, python-celery-3.0.19-5.fc20, python-billiard-2.7.3.34-1.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing python-kombu-2.5.16-1.fc20 python-celery-3.0.19-5.fc20 python-billiard-2.7.3.34-1.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-0435/python-kombu-2.5.16-1.fc20,python-celery-3.0.19-5.fc20,python-billiard-2.7.3.34-1.fc20 then log in and leave karma (feedback).
Thanks so much, I tested the RPMs as requested, and I can confirm that Celery can start now.
python-kombu-2.5.16-1.fc19, python-celery-3.0.15-4.fc19, python-billiard-2.7.3.34-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
python-kombu-2.5.16-1.fc20, python-celery-3.0.19-5.fc20, python-billiard-2.7.3.34-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.