Am Sonntag, den 05.01.2014, 15:09 +0100 schrieb Guillem Jover:
On Thu, 2014-01-02 at 17:22:33 +, Jonathan Dowland wrote:
You raise some very valid points and §I appreciate your concerns and
perhaps should rephrase my request so that I'm suggesting subsuming the
most common used features
Le samedi, 4 janvier 2014, 19.54:05 Stefano Rivera a écrit :
Hi Jonathan (2014.01.02_19:22:33_+0200)
* having to support remote signing
It would be fair enough to stderr not supported, please use the
older tool in devscripts and error 1 if such an argument was
provided. That would
On Sunday 05 January 2014 11:58:07 Didier 'OdyX' Raboud wrote:
Le samedi, 4 janvier 2014, 19.54:05 Stefano Rivera a écrit :
Hi Jonathan (2014.01.02_19:22:33_+0200)
* having to support remote signing
It would be fair enough to stderr not supported, please use the
older tool in
On Thu, 2014-01-02 at 17:22:33 +, Jonathan Dowland wrote:
You raise some very valid points and §I appreciate your concerns and
perhaps should rephrase my request so that I'm suggesting subsuming the
most common used features of debsign and perhaps as part of a staged
migration (compat
Hi Jonathan (2014.01.02_19:22:33_+0200)
* having to support remote signing
It would be fair enough to stderr not supported, please use the older
tool in devscripts and error 1 if such an argument was provided. That
would be pragmatic if (as I suspect) -r is rarely used.
Aww. I'm a
On Mon, Dec 30, 2013 at 12:27:29PM +0100, Guillem Jover wrote:
* signing would get rafactored into a new program so that users do
not need to manually mangle the .changes file, rebuild or require
devscripts for something that was possible out-of-the-box.
I chose to read that as debsign
Hi!
On Thu, 2014-01-02 at 09:24:55 +, Jonathan Dowland wrote:
On Mon, Dec 30, 2013 at 12:27:29PM +0100, Guillem Jover wrote:
* signing would get rafactored into a new program so that users do
not need to manually mangle the .changes file, rebuild or require
devscripts for
You raise some very valid points and §I appreciate your concerns and
perhaps should rephrase my request so that I'm suggesting subsuming the
most common used features of debsign and perhaps as part of a staged
migration (compat symlink to debsign binary name in the phase 1, real
name dpkg-sign or
On Mon, Dec 30, 2013 at 12:27:29PM +0100, Guillem Jover wrote:
I guess it's probably a good idea to switch the default, becuse I
assume most maintainers do more test builds than final ones. Or users
who either don't have gpg installed or don't have a gpg key. Although
with the current
Roger Leigh writes (Re: Bug#733029: dpkg-buildpackage: disable signing by
default (-us -uc should be the default)):
On the sbuild/buildd side, we have run dpkg-buildpackage with
-us -uc by default for years. If you do enable signing, as is
the case for buildd uploads, we run debsign
Hi!
[ CCing debian-devel to get input from possibly afftected users. ]
On Tue, 2013-12-24 at 15:14:22 +0800, Paul Wise wrote:
Package: dpkg-dev
Severity: wishlist
File: /usr/bin/dpkg-buildpackage
X-Debbugs-CC: Arno Töll a...@debian.org
Please disable signing by default. Generally the
* Guillem Jover guil...@debian.org, 2013-12-30, 12:27:
I guess it's probably a good idea to switch the default, becuse I
assume most maintainers do more test builds than final ones.
ACK
If most people agree this would be an improvement, and not just an
annoyance, I'm happy to do the change.
On Mon, 30 Dec 2013, Jakub Wilk wrote:
* Guillem Jover guil...@debian.org, 2013-12-30, 12:27:
I guess it's probably a good idea to switch the default, becuse I
assume most maintainers do more test builds than final ones.
ACK
And also, it should be friendly to non-maintainers who are just
13 matches
Mail list logo
