[Pkg-privacy-maintainers] RFS: codecrypt, the post-quantum cryptography tool
exa.exa at gmail.com
Mon Mar 7 09:46:28 UTC 2016
Thanks for the comments, I'll try try to address everything asap.
For the packaging I'd go with (b), it seems to separate the conccepts in
the most correct way. I'll create some repo for packaging on github, I
guess we can eventually move it to alioth project if everything works out
fine. The branching required in development repo for keeping debian origs
intact would probably result in a situation that would be a bit hard to
explain to non-debian people, with lots of development-unrelated
branches/tags. Also thanks for examples on all the possibilities.
- The COPYING files are okay, it's the method that's recommended here:
http://www.gnu.org/licenses/gpl-howto.html paragraphs 8-9. I'll clarify the
- About the lintian - I just fix warnings, they usually remind me something
that I wanted to fix earlier but was too lazy :D
- For the https links I'll need to find a certificate for my site, it may
take some time.
I'll report back as soon as I correct the problems.
On Sat, 5 Mar 2016 at 19:07 Ximin Luo <infinity0 at debian.org> wrote:
> Miroslav Kratochvil:
> > Anyway, I guess that the workflow stays mostly the same and the rest of
> > whole gbp framework with upstream branches&tags&so simply doesn't get
> > here, is it right? At least gbp-dch and similar tools kindof refuse to
> > without related branchwork.
> It's still preferable to use separate branches. The reason is that Debian
> is very release-oriented, and version you give in debian/changelog is
> supposed to be exactly the same tarball that was released that the Debian
> packaging is based on.
> For example your current repo would not be suitable, because you made
> extra commits to the non-Debian part of your software on top of v1.7.3. The
> correct Debian version string in this case would be something like
> 1.7.3+git20160305.34ede39-1 but in practise it's easier to just stick with
> released versions, and use separate branches.
> Easiest way forward for you probably would be to remove debian/, commit
> this, address the other issues (a-e) from my other emails, release 1.7.4,
> commit this, then you have a few options:
> (a) re-insert debian/ on a separate "debian" branch and update
> debian/changelog to say 1.7.4-1. You should probably also add the following
> to debian/gbp.conf:
> upstream-tree = master
> debian-branch = debian
> (b) keep the debian packaging files in a completely separate repo, and
> import your tarball releases using `gbp import-orig`. You can see  for
> an example. With this option, it would be preferable to keep this repo on
> Debian's infrastructure, in which case you should create an account on
> alioth and join our pkg-privacy group .
>  https://alioth.debian.org/projects/pkg-privacy/
> (c) Combine (a) and (b) together, with the combined repo hosted on Debian
> alioth. This is a bit more complex but you can see  for an example:
> The gbp commands to run to make (c) work are a little bit more complex;
> take a look at upstream-vcs-tag in `man gbp-import-orig` or ask me on IRC
> for help.
> (end stuff about repo layout)
> Apart from that, everything looks great! I'm kind of impressed that your
> first packaging attempt didn't show up any lintian warnings/errors :)
> There's a few minor things to fix though:
> - use https:// links
> - though firefox complains about insecure connection when I try to visit
> - add Vcs-Browser and Vcs-Git fields, be sure to use https://
> - "encryption&signing" -> "encryption and signing"
> - use https:// links
> - "GPL-3" should instead say "LGPL-3+"
> GPG: ed25519/56034877E1F87C35
> GPG: rsa4096/1318EFAC5FBBDBCE
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pkg-privacy-maintainers