15
0
forked from pool/python-celery
Files
python-celery/python-celery.spec

93 lines
2.8 KiB
RPMSpec
Raw Normal View History

#
# spec file for package python-celery
#
# Copyright (c) 2013 SUSE LINUX Products GmbH, Nuernberg, Germany.
#
# All modifications and additions to the file contributed by third parties
# remain the property of their copyright owners, unless otherwise agreed
# upon. The license for this file, and modifications and additions to the
# file, is the same license as for the pristine package itself (unless the
# license for the pristine package is not an Open Source License, in which
# case the license is the MIT License). An "Open Source License" is a
# license that conforms to the Open Source Definition (Version 1.9)
# published by the Open Source Initiative.
# Please submit bugfixes or comments via http://bugs.opensuse.org/
#
Name: python-celery
- Update to 3.0.14: - Now depends on Kombu 2.5.6 - Now depends on billiard 2.7.3.20 - execv is now disabled by default. It was causing too many problems for users, you can still enable it using the CELERYD_FORCE_EXECV setting. execv was only enabled when transports other than amqp/redis was used, and it's there to prevent deadlocks caused by mutexes not being released before the process forks. Sadly it also changes the environment introducing many corner case bugs that is hard to fix without adding horrible hacks. Deadlock issues are reported far less often than the bugs that execv are causing, so we now disable it by default. Work is in motion to create non-blocking versions of these transports so that execv is not necessary (which is the situation with the amqp and redis broker transports) - Chord exception behavior defined (Issue #1172). From Celery 3.1 the chord callback will change state to FAILURE when a task part of a chord raises an exception. It was never documented what happens in this case, and the actual behavior was very unsatisfactory, indeed it will just forward the exception value to the chord callback. For backward compatibility reasons we do not change to the new behavior in a bugfix release, even if the current behavior was never documented. Instead you can enable the CELERY_CHORD_PROPAGATES setting to get the new behavior that will be default from Celery 3.1. See more at chord-errors. - worker: Fixes bug with ignored and retried tasks. The on_chord_part_return and Task.after_return callbacks, nor the task_postrun signal should be called when the task was OBS-URL: https://build.opensuse.org/package/show/devel:languages:python/python-celery?expand=0&rev=75
2013-02-08 20:24:43 +00:00
Version: 3.0.14
Release: 0
Url: http://celeryproject.org
2012-03-10 17:57:30 +00:00
Summary: Distributed Task Queue
License: BSD-3-Clause
Group: Development/Languages/Python
Source: celery-%{version}.tar.bz2
BuildRoot: %{_tmppath}/%{name}-%{version}-build
2012-03-10 17:57:30 +00:00
BuildRequires: python-SQLAlchemy
BuildRequires: python-cl
BuildRequires: python-curses
BuildRequires: python-dateutil
BuildRequires: python-devel
BuildRequires: python-distribute
2012-03-10 17:57:30 +00:00
BuildRequires: python-eventlet
BuildRequires: python-gevent
- Update to 3.0.14: - Now depends on Kombu 2.5.6 - Now depends on billiard 2.7.3.20 - execv is now disabled by default. It was causing too many problems for users, you can still enable it using the CELERYD_FORCE_EXECV setting. execv was only enabled when transports other than amqp/redis was used, and it's there to prevent deadlocks caused by mutexes not being released before the process forks. Sadly it also changes the environment introducing many corner case bugs that is hard to fix without adding horrible hacks. Deadlock issues are reported far less often than the bugs that execv are causing, so we now disable it by default. Work is in motion to create non-blocking versions of these transports so that execv is not necessary (which is the situation with the amqp and redis broker transports) - Chord exception behavior defined (Issue #1172). From Celery 3.1 the chord callback will change state to FAILURE when a task part of a chord raises an exception. It was never documented what happens in this case, and the actual behavior was very unsatisfactory, indeed it will just forward the exception value to the chord callback. For backward compatibility reasons we do not change to the new behavior in a bugfix release, even if the current behavior was never documented. Instead you can enable the CELERY_CHORD_PROPAGATES setting to get the new behavior that will be default from Celery 3.1. See more at chord-errors. - worker: Fixes bug with ignored and retried tasks. The on_chord_part_return and Task.after_return callbacks, nor the task_postrun signal should be called when the task was OBS-URL: https://build.opensuse.org/package/show/devel:languages:python/python-celery?expand=0&rev=75
2013-02-08 20:24:43 +00:00
BuildRequires: python-kombu >= 2.5.6
2012-03-10 17:57:30 +00:00
BuildRequires: python-mock
BuildRequires: python-nose-cover3
BuildRequires: python-pyOpenSSL
%if 0%{?suse_version} == 1110
BuildRequires: python-importlib
BuildRequires: python-ordereddict
BuildRequires: python-unittest2
# See changes entry from "Jun 6 17:31:29 UTC 2012":
# TODO/FIXME: Drop this as as soon as possible, d:l:p already has a newer kombu,
Conflicts: python-kombu >= 2.5
Requires: python-importlib
Requires: python-ordereddict
%endif
Requires: python-anyjson
- Update to 3.0.14: - Now depends on Kombu 2.5.6 - Now depends on billiard 2.7.3.20 - execv is now disabled by default. It was causing too many problems for users, you can still enable it using the CELERYD_FORCE_EXECV setting. execv was only enabled when transports other than amqp/redis was used, and it's there to prevent deadlocks caused by mutexes not being released before the process forks. Sadly it also changes the environment introducing many corner case bugs that is hard to fix without adding horrible hacks. Deadlock issues are reported far less often than the bugs that execv are causing, so we now disable it by default. Work is in motion to create non-blocking versions of these transports so that execv is not necessary (which is the situation with the amqp and redis broker transports) - Chord exception behavior defined (Issue #1172). From Celery 3.1 the chord callback will change state to FAILURE when a task part of a chord raises an exception. It was never documented what happens in this case, and the actual behavior was very unsatisfactory, indeed it will just forward the exception value to the chord callback. For backward compatibility reasons we do not change to the new behavior in a bugfix release, even if the current behavior was never documented. Instead you can enable the CELERY_CHORD_PROPAGATES setting to get the new behavior that will be default from Celery 3.1. See more at chord-errors. - worker: Fixes bug with ignored and retried tasks. The on_chord_part_return and Task.after_return callbacks, nor the task_postrun signal should be called when the task was OBS-URL: https://build.opensuse.org/package/show/devel:languages:python/python-celery?expand=0&rev=75
2013-02-08 20:24:43 +00:00
Requires: python-billiard >= 2.7.3.20
- Update to 2.4.0: * Now supports Python 3. * Fixed deadlock in worker process handling (Issue #496). * AMQP Result backend: Now expires results by default. * Eventlet: Fixed problem with shutdown (Issue #457). * Broker transports can be now be specified using URLs * The deprecated celery.loaders.setup_loader() function has been removed. * The CELERY_TASK_ERROR_WHITELIST setting has been replaced by a more flexible approach (Issue #447). * There are additional deprecations. * No longer depends on pyparsing. * Now depends on Kombu 1.4.3. * CELERY_IMPORTS can now be a scalar value (Issue #485). * Fixed a memory leak when using the thread pool (Issue #486). * The statedb was not saved at exit. * Adds EMAIL_USE_TLS to enable secure SMTP connections (Issue #418). * Now handles missing fields in task messages as documented in the message format documentation. * Fixed race condition in celery.events.state (celerymon/celeryev) where task info would be removed while iterating over it (Issue #501). * The Cache, Cassandra, MongoDB, Redis and Tyrant backends now respects the CELERY_RESULT_SERIALIZER setting (Issue #435). * Logging calls no longer manually formats messages, but delegates that to the logging system, so tools like Sentry can easier work with the messages (Issue #445). * celeryd_multi now supports a stop_verify command to wait for processes to shutdown. * Cache backend did not work if the cache key was unicode (Issue #504). * New setting CELERY_RESULT_DB_SHORT_LIVED_SESSIONS added, which if OBS-URL: https://build.opensuse.org/package/show/devel:languages:python/python-celery?expand=0&rev=39
2011-11-04 17:32:08 +00:00
Requires: python-dateutil
2012-03-10 17:57:30 +00:00
Recommends: python-curses
Recommends: python-pyOpenSSL
Suggests: python-eventlet
Suggests: python-gevent
Suggests: python-pymongo
Suggests: python-python-daemon
2012-03-10 17:57:30 +00:00
Suggests: python-pytyrant
%if 0%{?suse_version} && 0%{?suse_version} <= 1110
%{!?python_sitelib: %global python_sitelib %(python -c "from distutils.sysconfig import get_python_lib; print get_python_lib()")}
%py_requires
%else
BuildArch: noarch
%endif
%description
Celery is an open source asynchronous task queue/job queue based on
distributed message passing. It is focused on real-time operation,
but supports scheduling as well.
%prep
%setup -q -n celery-%{version}
%build
python setup.py build
%install
python setup.py install --prefix=%{_prefix} --root=%{buildroot}
#TODO: Reenable if errors are fixed:
#%%check
#python setup.py test
2012-03-10 17:57:30 +00:00
%files
%defattr(-,root,root,-)
%{python_sitelib}/*
%doc Changelog README.rst TODO
%{_bindir}/camqadm
%{_bindir}/celery*
%changelog