Hi: On Mon, 22 Feb 2016 19:56:06 -0500 Harlan Lieberman-Berg <[email protected]> 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 > <[email protected]>, 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 _______________________________________________ Letsencrypt-devel mailing list [email protected] https://lists.alioth.debian.org/mailman/listinfo/letsencrypt-devel
