Bug#703178: RFS: vizigrep/1.0-1 [ITP]

[Jakub Wilk <jwilk@debian.org>]

(I don't intend to sponsor this package.)

* Jason J. Herne <hernejj@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