Comment 4 for bug 715830

* You added some files since last time, you need to do a new release with this :)

* I'm not sure about shipping the Grip.py gi override in a separate package (python-grip). I think most of people will expect just install the gir package, isn't it? shouldn't it make more sense to ship it in the gir package rather?

* from http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html, the -dev package name should be: libgrip-0.10-dev
(see objdump -p debian/libgrip-0.1-0/usr/lib/libgrip-0.1.so.0.0.0 | sed -n 's/^[[:space:]]*SONAME[[:space:]]*//p' | sed 's/\(0-9\)\.so\./\1/; s/\.so\.//; s/$/-dev/'). This is not important IMHO and really depends on how you want to handle it (multiple -dev package? just one -dev without soname in it?).

* if you want to keep the python- package,
can you fix that new lintian warning btw:

$ lintian-info --tags old-versioned-python-dependency
N: old-versioned-python-dependency
N:
N: This package appears to be an architecture-independent Python module
N: but has a dependency on a version of python less than a particular
N: version, doesn't use python-support and no Python-Version control
N: field. This normally means that the package isn't using the current
N: Python policy; most architecture-independent Python packages will work
N: with any future version of Python if they follow the new policy.
N:
N: If this package really does require only a particular range of Python
N: versions and uses python-central, add a Python-Version control field
N: (as described in 2.3 of the Python policy) to resolve this warning.
N:
N: Severity: normal, Certainty: certain
N:

really optional:
You build libgrip.pc libgrip-0.1.pc (libgrip.pc comes from libgrip.pc.in). You ship the -0.1.pc, maybe you should mv instead of cp

for the future: shipping the examples source (in its own package for instance or in -dev) can be interesting.

Apart frorm that, all the cryptic gir- package is perfectly handled! nice work :)