On 2016-04-12 09:19 +0200, Ansgar Burchardt wrote:
> Paul Wise writes:
>> On Tue, 22 Oct 2013 10:42:51 +0200 Ansgar Burchardt wrote:
>>> uscan would store the signature for the upstream tarball as
>>> obtained via pgpsigurlmangle=... in the debian/ directory
>>
>> ISTR another
On Wed, 2016-04-13 at 01:15 +0800, Paul Wise wrote:
> On Tue, 2016-04-12 at 18:24 +0200, Ansgar Burchardt wrote:
> > Why include the fingerprint in the filename instead of just
> > including
> > multiple signatures in the single .asc file? That is what we do
> > for InRelease and Release.gpg too.
On Tue, 2016-04-12 at 18:24 +0200, Ansgar Burchardt wrote:
> Why include the fingerprint in the filename instead of just including
> multiple signatures in the single .asc file? That is what we do for
> InRelease and Release.gpg too.
For a start: dak doesn't allow updating files in pool/
--
On Tue, 2016-04-12 at 21:52 +0800, Paul Wise wrote:
> On Tue, 2016-04-12 at 09:19 +0200, Ansgar Burchardt wrote:
> For a given upstream tarball the upstream signature should go in a
> > file
> > with the extension `.asc`. For example, for
> > dune-common_2.4.1.orig.tar.xz
> > the signature
On Tue, 2016-04-12 at 12:06 -0400, Daniel Kahn Gillmor wrote:
> .asc files can already contain multiple signatures -- i guess i have no
> problem with splitting them out if we want, as long as the tooling for
> doing so is easy for people to use.
Having separate keys allows the addition of
On Tue 2016-04-12 11:12:44 -0400, Paul Wise wrote:
> On Tue, 2016-04-12 at 10:26 -0400, Daniel Kahn Gillmor wrote:
>
>> I'm not sure that we need the [] in that specification.
>
> This allows for multiple signers: an upstream release team to have
> multiple signers attesting that the build of the
On Tue, 2016-04-12 at 10:26 -0400, Daniel Kahn Gillmor wrote:
> I'm not sure that we need the in that specification.
This allows for multiple signers: an upstream release team to have
multiple signers attesting that the build of the source tarball from git is
bitwise reproducible, or an
On Tue 2016-04-12 10:00:09 -0400, Osamu Aoki wrote:
> I assume "create" means "create a copy of the upstream-generated
> signature" as foo_0.1.2.orig.tar.gz..asc which can be
> verified by the keyring debian/upstream/signing-key.pgp in the older
> package.
I'm not sure that we need the in that
On Tue, 2016-04-12 at 21:14 +0900, Osamu Aoki wrote:
> I assume "create" means "create a copy of the upstream-generated
> signature" as foo_0.1.2.orig.tar.gz..asc which can be
> verified by the keyring debian/upstream/signing-key.pgp in the older
> package.
Correct.
> I am a bit confused what
On Tue, 2016-04-12 at 09:19 +0200, Ansgar Burchardt wrote:
> For a given upstream tarball the upstream signature should go in a file
> with the extension `.asc`. For example, for
> dune-common_2.4.1.orig.tar.xz
> the signature should be in
> dune-common_2.4.1.orig.tar.xz.asc
Is there any
Hi,
On Tue, Apr 12, 2016 at 09:19:41AM +0200, Ansgar Burchardt wrote:
> Paul Wise writes:
> > On Tue, 22 Oct 2013 10:42:51 +0200 Ansgar Burchardt wrote:
> >> uscan would store the signature for the upstream tarball as
> >> obtained via pgpsigurlmangle=... in the debian/
Paul Wise writes:
> On Tue, 22 Oct 2013 10:42:51 +0200 Ansgar Burchardt wrote:
>> uscan would store the signature for the upstream tarball as
>> obtained via pgpsigurlmangle=... in the debian/ directory
>
> ISTR another idea was to place the upstream signature alongside the
>
On Tue, 22 Oct 2013 10:42:51 +0200 Ansgar Burchardt wrote:
> uscan would store the signature for the upstream tarball as
> obtained via pgpsigurlmangle=... in the debian/ directory
ISTR another idea was to place the upstream signature alongside the
upstream tarball instead of inside the debian/
Package: devscripts
Version: 2.13.4
Severity: wishlist
File: /usr/bin/uscan
Hi,
It would be nice if uscan would store the signature for the upstream tarball as
obtained via pgpsigurlmangle=... in the debian/ directory. This would allow
checking the signature later without having to rely on the
14 matches
Mail list logo