(I don't intend to sponsor this package.)
* Jason J. Herne <hern...@gmail.com>, 2013-03-16, 09:40:
http://mentors.debian.net/debian/pool/main/v/vizigrep/vizigrep_1.0-1.dsc
Why does the source package use a different tarball than the one uscan
downloads?
Policy §12.5 says that “packages distributed under […] the GNU GPL […]
should refer to the corresponding files under
/usr/share/common-licenses”. So please refer to the actual _file_ name,
not only the directory name.
§12.5 also says that “the copyright file must say where the upstream
sources (if any) were obtained”.
Upstream should include full license text in their tarballs; see GPLv2
§1.
Why section python? Users shouldn't care what language it's implemented
in.
Why priority extra? I'd use optional.
Package synopsis doesn't need to start with an uppercase letter; see
Developer's Reference §6.2.2.
What is build-dependency on python-support for? As far as I can see,
this package doesn't use it.
You need X-Python-Version field; see Python Policy §2.3.
You don't need to remove *-stamp files explicitly; dh_clean takes care
of this in compat>=7.
What are configure and configure-stamp targets for? They don't do
anything useful.
There are no architecture-specific packages, so build-arch and
binary-arch targets shouldn't do anything.
Calling dh_installdirs before “$(MAKE) install” looks weird. Upstream
makefile shouldn't require any of these directories to exist beforehand;
if it does, please get it fixed.
The changelog is formatted in a strange way. It's usual to put blank
lines after each package "title" and before each "trailer"; see e.g. how
coreutils changelog is formatted:
http://packages.debian.org/changelogs/pool/main/c/coreutils/current/changelog.txt
Lintian (from experimental) emits:
W: vizigrep source: out-of-date-standards-version 3.9.3 (current is 3.9.4)
lintian4python emits (among others):
p: vizigrep source: insufficient-build-dependency-on-python-helper dh_python2 =>
python (>= 2.6.6-3~)
e: vizigrep: pyflakes-undefined-name usr/share/vizigrep/GrepEngine.py:77:
search_dir
e: vizigrep: pyflakes-undefined-name usr/share/vizigrep/GrepEngine.py:80:
filename
e: vizigrep: pyflakes-undefined-name usr/share/vizigrep/mbox.py:143: gtk
Last but not least, it doesn't start here:
$ vizigrep
Traceback (most recent call last):
File "vizigrep", line 4, in <module>
from gi.repository import Gtk, GObject
ImportError: No module named gi.repository
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130316191626.ga5...@jwilk.net