[Letsencrypt-devel] Bug#815199: ITP: acme-tiny -- letsencrypt tiny python client

[Jeremías Casteglione]

Hi:

On Mon, 22 Feb 2016 19:56:06 -0500
Harlan Lieberman-Berg <hlieberman at setec.io> wrote:

> Just a few more things.  One, you should use the Expat license, not
> MIT, if it matches, as per Debian Policy.  There are multiple
> versions of the MIT license, so it helps with
> clarity.
> (https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/)

Done! (commit 33f9a56). I'm not sure if I did it right though, I used
the "complex" example from the link above.

I chose MIT license initially because working on another package (numad)
some months ago I was instructed to use the same license as upstream,
for debian/* files, as they say it's better/easier if you need to send
patches to upstream, etc...

So this time I used the dh-make MIT license template[0], which sets the
license for debian/* as MIT.

 0: /usr/share/debhelper/dh_make/licenses/mit

Based on the policy then, shouldn't 'dh_make -c mit' use the Expat
license and/or symlink mit to expat or something like that? Currently I
don't see an expat license being provided either nor by dh-make nor
under /usr/share/common-licenses...

Am I missing something? Should I ask/report to dh-make people?

> If you want to maintain this package under the Debian Let's Encrypt
> team, you should set the maintainer to Debian Let's Encrypt
> <letsencrypt-devel at lists.alioth.debian.org>, and set yourself under
> Uploaders.

Done! (commit d9fae40)

> I might not personally have bothered with the upstream changelog file
> since they don't ship one themselves; you could simply suppress the
> lintian tags about it.  It's fine to leave it the way it is, though.

Well, the changelog is being "implicitly" provided (git log), isn't it?
Also, as a debian user, I expect/like the packages to include it.

> Other than that, it looks good!
> 

Good, thank you all for looking into it.

Cheers,


-- 
Jeremías