Bug#743489: license issues

Sebastiaan Couwenberg sebastic at xs4all.nl
Sat Apr 5 21:15:43 UTC 2014

Hash: SHA512

Hi Markus,

On 04/05/2014 09:55 PM, Markus Wanner wrote:
> I took some time reviewing your changes to the postgis package.

Thanks for your review.

> For pgapt, it's beneficial if you do not change the release to 
> "unstable" until you really intend to release. Because there, we
> have special logic that automatically creates increasing
> ~git-$REVID revision numbers.

That's sounds a bit similar to the pkg-perl workflow, I'll keep that
in mind for postgis.

> I admittedly didn't know cme, and I'm willing to learn. However, it
> a) made reviewing a lot harder than necessary and b) broke things.
> Please do such reformatting only after modifications have settled
> and other maintainers agree to the change. So as to prevent
> conflicts with other's work and ease review.
> That change hides an increase in the required gdal version, which
> broke wheezy, saucy and precise on pgapt. As I couldn't immediately
> figure out how to let cme only do the reformatting (or do anything
> useful at all), I had a pretty hard time comparing the two control
> files. In the end, I simply reverted to the last known-working
> version and manually re-added (hopefully) all of the required and
> good changes, manually. (In addition, I don't like the uneven
> indentation with so many spaces... looks weird IMO. But again, feel
> free to raise arguments for using cme.)

I like cme to sanity check the control file, and because it provides
an easy way to maintain a uniform format for all team packages. It's
use is recommended in the policy, but not mandatory.


cme has some behavior I don't like as much, like the automatic
Standards-Version adjustment, and stripping of versions in dependency
when the version requirement is met by all version in Debian.

While reverting those cme changes, I also changed the libgdal-dev
version which didn't take backports into account.

Does pgapt also do automatic generation of the control file, or manual
parsing that broke?

I understand that the increased gdal version broke backports, but I
don't understand why the reformatting broke anything.

> Why did you add the lintian override? The warning seems perfectly 
> appropriate to me. It's a debconf template and we should make it 
> translatable, somehow. I've just been lazy and couldn't figure out
> how to do that, yet. Reverted as well.

As I explained in the override comment, the warning seems to be a
false positive. The .in extension makes lintian think the control file
templates is a po-debconf template, while is only used to generated
the postgres version specific template files in debian/rules.


> I triggered another build on pgapt with the control file reverted
> and hope to see more green, again.

The control file revert also downgraded the debhelper dependency
version back from 9 to 8, so now debian/compat has a higher version
than the dependency requirement.

I've changes this, and a formatting issue of the Uploaders field in my
repo. You may want to cherry pick these changes, but I'm a bit
hesitant to push them now.

> Oh, and BTW, given it's a new source tarball, I'm not sure I can do
> the upload. I'm just a DM. But getting this sponsored shouldn't be
> an issue. Thanks again for contributing to the postgis package.

I won't use Andreas' Sponsoring of Blends initiative then, please have
a look at the changes in my repo and consider them before the upload.

Kind Regards,


- -- 
 GPG Key ID: 4096R/E88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/


More information about the Pkg-grass-devel mailing list