Hi, On 07/31/2017 11:34 AM, Andrey Rahmatullin wrote: > On Mon, Jul 31, 2017 at 05:30:46AM -0400, Paul Wise wrote: >>> How does this interact with git-based workflows? >> >> I don't use such workflows so I'm not sure, but at a guess; uscan and >> upstream tarballs aren't involved in your workflow, so you won't have >> upstream tarball signatures either and should manually verify the >> signatures on git tags (and commits) instead, which I don't think >> uscan can do yet, but I guess adding it to uscan would be feasible but >> then the signatures would not be stored alongside the generated >> tarball. > uscan isn't used, or needed, in the git-only workflow at all.
In purely git workflows (that pull remote git tags), sure, but then you'd not have debian/watch, and you wouldn't have lintian complaining about a missing .asc file in the .changes file because upstream doesn't actually sign any tarballs. But in workflows that do work with upstream tarballs and use git for Debian packaging, uscan is still useful. What I tend to do: uscan gbp import-orig ../package_newversion.orig.tar.gz (gbp import-orig potentially with --upstream-vcs-tag= to keep upstream's git history.) And there I do want uscan to actually check the signature of the new orig tarball it downloads. But that also means that as I'm using the orig tarball from upstream (and pristine-tar is just a weird way of storing it) I think it is semantically correct to include the .asc files in the .changes file. Regards, Christian
