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

Bug#528247: ITP: python-django-djapian -- Full-text search for Django

On Fri, Nov 27, 2009 at 03:29:20PM +0300, Mikhail Lukyanchenko wrote:
> - dget http://mentors.debian.net/debian/pool/main/p/python-django-djapian/python-django-djapian_2.3-0.1.dsc

OK, thanks.

Mostly this looks good, but a deeper inspection found a few issues (don't
be scared by the length of this mail - I've tried to provide plenty of

http://code.google.com/p/djapian/ seems to indicate djapian 2.3 requires
django 1.1 and Xapian 1.0.7.  I don't know if those are actually minimum
requirements (there weren't any changes in xapian-core or the Xapian python
bindings in 1.0.7 which seem a likely explanation) or just what upstream
have tested with, but unless you know better it's probably as well to
follow them.  Neither requirement is a problem for Debian unstable, or
for anyone backporting to lenny (lenny has Xapian 1.0.7 and a backported
version of django 1.1).

This line in debian/rules doesn't seem to be used or needed:
PKG = $(shell dh_listpackages)

What's the origin of the licence boilerplate in debian/copyright?  The
upstream sources don't have (C) headers on any of the source files it
appears - the only mention of a licence seems to be in PKG-INFO:

Author: Alex Koshelev, Rafael "SDM" Sierra
License: New BSD License

Particularly, I don't see where the "django-tagging" used for the org name
in the third clause comes from.  Google suggests it is an unrelated django
application - is this just a left-over from copying the licence text from

Also, the copyright statements must have year(s), or the ftpmasters will
reject the package:

Ideally upstream would actually document their licence more explicitly,
and it would be good to politely point out that it would help their users
to do so, but debian/copyright certainly shouldn't invent information
but rather document when and how it was obtained - see "License II" here:

You might want to consider using the draft "machine-readable
debian/copyright" format to save yourself work later.  It seems likely
this will be adopted, and at some point it would probably then become

How you licence the Debian packaging is up to you, but GPLv3 seems an
odd choice for a BSD python package wrapping a GPLv2+ library.  Using
a stricter licence than Djapian's means that the Djapian developers
(or indeed the Xapian developers) can't just incorporate any changes from
your packaging which they find useful.

debian/changelog claims "Non-maintainer upload" and "-0.1" indeed indicates
this as such, which is wrong.  You would be the maintainer of this as a
sponsored upload, so the correct Debian version would be "2.3-1" (in
this case).

Also "new upstream version" is more conventional than "Imported Upstream
version 2.3" - see:

And the "Closes: #528247" really belongs in the section for the version
which actually gets uploaded, as that's the one which actually means the
ITP bug can be closed.

Some of the phrasing in the description seems a bit awkward - I think the
description would read better as something like (assuming I haven't
inadvertently changed the intended meaning):

Description: Search API for Django using Xapian
 Djapian provides full-text search in your Django project.
 Most features are provided by the Xapian library.  Djapian effectively
 serves as a Django-compatible adaptor for Xapian.
 Djapian's features include:

Has your GPG key been signed by anyone?  I found the key on
keyserver.ubuntu.com but only self-signed.  If you might want to become a
DM or DD in the future, you'll need to get it signed by existing DDs -
at least one for DM, and at least two for DD.

If you already have, you need to upload the signatures:

gpg --keyserver hkp://keyserver.ubuntu.com --send-keys F2D9A567


Reply to: