[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: celery

Hi Michael,

On Mon, Nov 21, 2011 at 01:53:52PM +0100, Michael Fladischer wrote:
> I am looking for a sponsor for my package "celery".

This has taken a while... As I noted in the original ITP, I'm interested
to see celery and django-celery in Debian and hence willing to upload
immediately after the problems below are fixed. Great job besides those :-)

1) In celery, you're overriding dh_clean with rm -rf build, but you're never
   calling dh_clean. This results in:
   debian/files                            |only
   debian/python-celery                    |only
   debian/python-celery-doc                |only
   debian/python-celery-doc.debhelper.log  |only
   debian/python-celery-doc.substvars      |only
   debian/python-celery.debhelper.log      |only
   debian/python-celery.postinst.debhelper |only
   debian/python-celery.prerm.debhelper    |only
   debian/python-celery.substvars          |only
   debian/tmp                              |only

2) dpkg-source complains about the unexpected upstream changes in both:
   /camqadm.1                              |only
   /celerybeat.1                           |only
   /celeryctl.1                            |only
   /celeryd-multi.1                        |only
   /celeryd.1                              |only
   /celeryev.1                             |only
   celery.egg-info/PKG-INFO                |    2 +-
   celery.egg-info/SOURCES.txt             |    1 +
   celery.egg-info/requires.txt            |    2 +-

   /djcelerymon.1                          |only
   django_celery.egg-info/PKG-INFO         |    2 +-
   django_celery.egg-info/SOURCES.txt      |    8 ++++++++

3) Both source packages are different from what's present in SVN;
strange thing is, in celery SVN seems newer than .dsc, in django-celery,
the opposite. Could you sync them up?

4) Celery's extended description is excellent; django-celery's not,
however. I think a better description of it is warranted.

5) Last name first for the Maintainer's name is not against policy, but
is a bit weird — I've never seen it before. I guess it's okay if you've
been using it in your previous packages...

Best regards,

Reply to: