Hi Paul, Christian, Christian Seiler <christ...@iwakd.de> writes: > On 07/31/2017 10:54 AM, Paul Wise wrote: >> On Mon, Jul 31, 2017 at 4:24 AM, Ole Streicher wrote: >>> is not really helpful to me; at least I did not find a mention in the >>> Debian policy that the signature should be included in the .changes >>> file. Also, it seems that the standard (pdebuild) toolchain does not >>> include it by default. >> >> Policy documents current practice rather than describing what >> practices should be taken, so I think that we will only get this in >> policy once it is more common.
Hmm, but the right place to discuss what practices should be taken is debian-devel, right? Especially if it has impact on the packaging workflow. That's why I was wondering why it was not discussed there. >> The standard toolchain here is uscan, not pdebuild, and there is a bug >> asking placing the signatures in the correct place open already, it >> just needs someone to do the work: Shouldn't this be fixed before a new error is introduced? > How does this interact with git-based workflows? Currently I use > pristine-tar (in combination with gbp) for all of the packages I > maintain. [1] Oops, this is my case as well. At least my usual workflow: gbp import-orig --uscan gbp pq rebase gbp dch -R --commit gbp buildpackage --git-tag seems to be broken here -- at least the signature is not in the pristine-tar branch (and I don't know how it shall get there, and how it shall get back out). Since I am not able to fix uscan (as an almost-perl-illiterate), and I also don't know about how this will influence the git-buildpackage workflow, I would for the moment just ignore the error. Any other advice? Best regards Ole
