Re: Invoking ‘init’ from an init.d script (Wheezy)

[Tollef Fog Heen]

]] David Kalnischkies 

> It is on my TODO list to drop the --force-yes flag and replace it with
> specialised --allow-* flags 'just' to force users to acknowledge what
> it is they are saying yes to. Somehow most people are way more willing
> to add --allow-everything than --allow-prostate-exam …

That would be great.  Currently, I'm not aware of any way to say
«downgrade this package and any necessary dependencies and don't ask»
short of --force-yes (or listing all the necessary packages to be
downgraded with their versions).  If there is a way, I'd love to be told
about it.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/m27fr8yqgn@rahvafeir.err.no

Adding support for LZIP to dpkg, using that instead of xz, archive wide

[Thomas Goirand]

Dear friends,

I've been using xz compression for a long time, but I see a big defect
which is today pushing me to turn it off for the .orig.tar file. The
issue is that depending on the version of xz-utils, it produces a
different output.

We use "git archive" within the PKG OpenStack team to generate this
tarball (which is more or less the same as pristine-tar, except we use
upstream tags rather than a pristine-tar branch). The fact that xz
produces a different result makes it not reproducible. As a consequence,
it is very hard for us to use this system across distributions (ie: use
that in both Debian and Ubuntu, or in Sid & Jessie). We need consistency.

As a friend puts it:

"This is a fundamental problem/defect with xz. This (and a lot of other
such defects, e.g. non-robustness of xz archives that easily lead to
file corruption etc) are the reason that there is lzip (and which is why
gnu.org has, on a technical basis, decided that lzip is official
gzip-successor for gnu software releases when they come in tarballs).

So it'd be super nice to have LZIP support in dpkg, and use that instead
of xz, archive wide.

Your thoughts everyone? Is there any reason why we wouldn't do that?

Cheers,

Thomas Goirand (zigo)


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/557be879.5060...@debian.org

Re: Facilitating external repositories

[Tollef Fog Heen]

]] Wouter Verhelst 

> On Mon, Jun 08, 2015 at 09:12:51AM +0200, Tollef Fog Heen wrote:
> > ]] Wouter Verhelst 
> > 
> > > Having said that, I do agree with you that we should not allow just
> > > about anyone to create a repository which will be automatically trusted
> > > by the whole Debian system. Establishing such a trust chain should,
> > > indeed, require some vetting by at least one Debian Developer, so that
> > > malicious packages can be rejected, if needs be.
> > 
> > I've always been a bit unhappy about the idea of using keys to decide
> > which repositories are trusted or not.  The signature is there primarily
> > to act as an anti-MITM tool.  This is a bit similar (or maybe
> > equivalent) to the difference between authentication and authorization
> > for access control.
> 
> What would you suggest instead?

With our current setup?  I don't really know, I think we'd need to add
some more information to some files.

Currently, there's no binding between an apt repository as listed in
sources.list and the corresponding key.  There is also no link between
an apt repository and allowed packages from that repository.

I could see us extending the apt preferences format to be something
like:

Package: *
Origin: Debian
Allowed-Keys: 2B90D010, C857C906, 518E17E1

Package: foo
Origin: fooCorp
Allowed-Keys: ABCD, EF12, 1234

Default priority for an unlisted package is < 0 (so can't be
installed).  We should probably use fingerprints and not short key ids
for the allowed-keys field (and we need something to manage them when
doing dist-upgrades and such).

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/m2381wypoi@rahvafeir.err.no

Re: Adding support for LZIP to dpkg, using that instead of xz, archive wide

[Paul Wise]

On Sat, Jun 13, 2015 at 4:23 PM, Thomas Goirand wrote:

> Is there any reason why we wouldn't do that?

It was already rejected by the dpkg maintainers twice.

https://bugs.debian.org/600094
https://bugs.debian.org/556960

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAKTje6F51gA_R0oCCgxbS=v5nssbiem5-iunvtsqu7j8qf8...@mail.gmail.com

Re: Facilitating external repositories

[Paul Wise]

On Sat, Jun 13, 2015 at 4:31 PM, Tollef Fog Heen wrote:

> I could see us extending the apt preferences format to be something
> like:

Why the preferences file instead of the sources.list file, which can
already be in deb822 format?

https://lists.debian.org/deity/2014/01/msg00055.html

Some more hardening we could do along with the key thing:

https://lists.debian.org/deity/2014/02/msg00017.html

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAKTje6GXX3GjHhre1KPza8M-O516BHPJZyR4s1m7DdO=xlx...@mail.gmail.com

Re: Facilitating external repositories

[Tollef Fog Heen]

]] Paul Wise 

> On Sat, Jun 13, 2015 at 4:31 PM, Tollef Fog Heen wrote:
> 
> > I could see us extending the apt preferences format to be something
> > like:
> 
> Why the preferences file instead of the sources.list file, which can
> already be in deb822 format?

Primarily because I wasn't aware of that format, and secondly the exact
implementation of where the information goes isn't core to my
suggestion.  The point is to tie apt repository, allowed packages and
expected key(s) together in a single place.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/m2wpz8x8m7@rahvafeir.err.no

Re: DEB_SIGN_KEYID vs DEBSIGN_KEYID

[Harald Dunkel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 06/08/15 18:48, Guido Günther wrote:
> On Sun, Jun 07, 2015 at 10:36:41AM +0200, Harald Dunkel wrote: Hi folks,
> 
> Trying to get rid of my old GPG key I stumbled over this:
> 
> For devscripts you can define a variable "DEBSIGN_KEYID". For dpkg it is 
> called "DEB_SIGN_KEYID". git-buildpackage doesn't
> 
>> Gbp has a keyid option. What would be the usecase for the env var? Cheers, 
>> -- Guido
> 

I did not ask for yet another environment variable. I am just
asking for a common way to configure the *default* GPG key to use
for *all* Debian tools signing packages. My suggestion would be
use the default-key configured in gpg.conf.

A command line option or local config file option should be used
to override the default. Thats not the case here.


Regards
Harri
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJVfDg6AAoJEAqeKp5m04HLBm0H/1pXoaDswagyZ6xC9HKEBj5O
lQZmAVmV/4HUWbdC71q4VpuqsjdZTDKa22axQk4lhpKL9SvY/WiwC3T0YyzVSNIb
igqwQOydrSFze2XEBKewYLbw14D+k9VrIDuX4wyEdpFjWoc5JIMaY7nmc6XWwqFa
H7eU3cG4VMCIvB3+g+/x3r2FbeMXoHQ836JfUorkHC3YrKpmBjKZgmqevuelgVCq
f2I23NhlIsOJbU66IzIGtzpUaEpPzjzX+1/is2yB8PcAOuR8v0dJgpm9lEVmQUNI
hmkdy80SrWksUfNKQ9aE8dY6G4smi3G2iNL8ixRdN+GodojkS0l64PuhGalilhY=
=n/2s
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/557c383a.9040...@afaics.de

Re: DEB_SIGN_KEYID vs DEBSIGN_KEYID

[Colin Tuckley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 13/06/15 15:03, Harald Dunkel wrote:

> I did not ask for yet another environment variable.

Ghod Forbid! But for info I also found that dput uses ~/.dput.cf

> I am just asking for a common way to configure the *default* GPG
> key to use for *all* Debian tools signing packages. My suggestion
> would be use the default-key configured in gpg.conf.

Agreed, we need *one* place where Debian related things look for a keyid
.

I'm not convinced that gpg.conf is the correct place, many of us use gpg
for things other than Debian and don't want to mix our gpg usage.
gpg.conf should be the default for general gpg usage, specialist usage
like Debian work should use something Debian specific *if* the user
wants it to be different.

Colin

- -- 
Colin Tuckley  |  +44(0)1223 830814  |  PGP/GnuPG Key Id
Debian Developer   |  +44(0)7799 143369  | 0x38C9D903

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVfEBrAAoJEPoMQQc4ydkDEEYQAOShSt+UjNAIZyUs+W0J3XIT
n+5O3kbpSQRkMjOGHdpH5113UlmfeBDvL+uUETsnhngCc6n2oW8sQDOTUzF9VMfY
Bm/pf2bh9kjg6RKsOKrtMQUDl4rtQ5iKd/o0EdkzBbTqn65aI7wnXdl8IlM+CZWf
pvet1dkyqg9kcik9hO7f0oXSDgn4QVSSqqmrQweHek8aun/zsF93U13A3E68szbq
R0ngm8e6OHNGipfIw/3/+T/SIHrTcvwQg73QxN0HxNxC5Z+9yEDngCi8oCiXKpAg
PwPeWk04zqFOBLDdv5A6VS5i4m3ZJ7NoTfoJLSshsAQkj0Ku1Fn5tktrT1LkVL9v
0ctOibtTDDeb0eomJ9wIobtsDI5F/qwy18SHj2t2OvxTJzxEKAYmtMe8mwvPSy/Y
tA4tZOxq7fJxRBHuiy6KGBthhpQxPblue4bVjhQgxIgFK6mFPp9XHwnFi+ifROYc
zFCdJqWL2i4VnNKlYTtnVwZEsZNLKKi4D1Cjqiz3SQ11K7lD6JjRpGC+r6SUQZa6
EXTmOHKkXq51OAY/UZGM2mqdADbwOfVnPTboTZXyHnhY9xeGblSu7ewBktbJoUD7
NUPxFObeqJo3xyoqPAp34BypOiAykmShf8C6PqiFBSZku0v++K9eEeb54pZUHEi1
0Eu9yVWhQL5G/TzDBb4u
=wi75
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/557c406b.5030...@debian.org

Bug#788633: ITP: ruby-rotp -- Ruby library for generating and verifying one time passwords

[Balasankar C]

Package: wnpp
Severity: wishlist
Owner: Balasankar C 

* Package name: ruby-rotp
  Version : 2.1.0
  Upstream Author : Mark Percival 
* URL : https://github.com/mdp/rotp
* License : Expat
  Programming Lang: Ruby
  Description : Ruby library for generating and verifying one time passwords


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150613153020.23372.6187.reportbug@sasalam

oldoldstable on DDPO

[Christoph Berg]

Hi,

over the past days, DDPO grew the ability to also show oldoldstable
(aka squeeze) versions, mostly for the benefit of those working on
squeeze-lts.

To use, append &version=oldoldstable to your DDPO URL, or set it via
the usual display configuration dialog at the bottom of the page.

https://qa.debian.org/developer.php?login=m...@debian.org&version=oldoldstable

The display logic is now generalized so it can also exclude the
"older" dists, e.g. &version=testing will just show testing and
later. The default is to show oldstable and up.

Christoph
-- 
c...@df7cb.de | http://www.df7cb.de/


signature.asc
Description: Digital signature

Re: oldoldstable on DDPO

[Luca Falavigna]

Hi,

2015-06-13 19:36 GMT+02:00 Christoph Berg :
> The display logic is now generalized so it can also exclude the
> "older" dists, e.g. &version=testing will just show testing and
> later. The default is to show oldstable and up.

Thanks for this new feature!
Would it be also possible to exclude from the view packages no longer
maintained in the selected suites (see #736715) ?

-- 
Cheers,
Luca


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CADk7b0Nc+pD_zBAhJ=vw8qfnetjgwhkyl+obciopg-dugg8...@mail.gmail.com

Re: oldoldstable on DDPO

[Christoph Berg]

Re: Luca Falavigna 2015-06-13 

> Would it be also possible to exclude from the view packages no longer
> maintained in the selected suites (see #736715) ?

That'd be more involved change. We used to only look at
unstable/experimental to gather maintainer information. The problem
with that is if a source package gets renamed, you will (hopefully)
still care about it in stable for security updates, so we need to
extract some maintainer information from stable as well.

I guess the fix is to check if the package still exists in unstable,
and maybe check for changed maintainer information. The logic for that
would be complex and probably have a lot of bugs or corner cases where
users would disagree over the Right Thing to do...

Christoph
-- 
c...@df7cb.de | http://www.df7cb.de/


signature.asc
Description: Digital signature

Re: oldoldstable on DDPO

[Sandro Tosi]

On Sat, Jun 13, 2015 at 2:31 PM, Christoph Berg  wrote:
> Re: Luca Falavigna 2015-06-13 
> 
>> Would it be also possible to exclude from the view packages no longer
>> maintained in the selected suites (see #736715) ?
>
> That'd be more involved change. We used to only look at
> unstable/experimental to gather maintainer information. The problem
> with that is if a source package gets renamed, you will (hopefully)
> still care about it in stable for security updates, so we need to
> extract some maintainer information from stable as well.

I think that is such a small corner case that can be handled adding
and extra package to your ddpo.

sid/experimental should be the source of truth here, as it used to be:
I'm not sure why it was changed, but now the situation is a bit
absurd, I have packages I used to maintain in oldstable that are still
listed on my ddpo :(

-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cab4xwxxpx8xhgph7hshkz0mteap_spdj9voax1kv2c0e2w-...@mail.gmail.com

Re: Adding support for LZIP to dpkg, using that instead of xz, archive wide

[Thomas Goirand]

On 06/13/2015 10:55 AM, Paul Wise wrote:
> On Sat, Jun 13, 2015 at 4:23 PM, Thomas Goirand wrote:
>> I've been using xz compression for a long time, but I see a big defect
>> which is today pushing me to turn it off for the .orig.tar file. The
>> issue is that depending on the version of xz-utils, it produces a
>> different output.
>> 
>> We use "git archive" within the PKG OpenStack team to generate this
>> tarball (which is more or less the same as pristine-tar, except we use
>> upstream tags rather than a pristine-tar branch). The fact that xz
>> produces a different result makes it not reproducible. As a
>> consequence, it is very hard for us to use this system across
>> distributions (ie: use that in both Debian and Ubuntu, or in Sid &
>> Jessie). We need consistency.
>> 
>> As a friend puts it:
>> 
>> "This is a fundamental problem/defect with xz. This (and a lot of
>> other such defects, e.g. non-robustness of xz archives that easily
>> lead to file corruption etc) are the reason that there is lzip (and
>> which is why gnu.org has, on a technical basis, decided that lzip is
>> official gzip-successor for gnu software releases when they come in
>> tarballs).
>> 
>> So it'd be super nice to have LZIP support in dpkg, and use that
>> instead of xz, archive wide.
>> 
>> Your thoughts everyone? Is there any reason why we wouldn't do that?
>> 
>> Cheers,
>> 
>> Thomas Goirand (zigo)
> 
> It was already rejected by the dpkg maintainers twice.
> 
> https://bugs.debian.org/600094
> https://bugs.debian.org/556960

Reading these bugs, am I right that the archive already supports lzip
for the orig.tar file? Because that's my issue: I don't really mind if
we use xz for the compression of the .deb files, but I need consistency
when generating the orig.tar.

Though, I had a try, and it doesn't look like dpkg-source -x supports
the .lz format unfortunately.

Now, regarding the fact that the maintainer closed the bugs, I see 2
issues the way he did it.

1/ First, he sites the fact that lzip isn't popular enough as the only
reason (did I miss another point of argumentation?). Well, it's
backed-up by the GNU project as the successor of gzip, and also, I
believe Debian is influential enough so that we may not have to care
about it. Also, a wise technical choice of this kind shouldn't be driven
by a popularity contest.

2/ Guillem wrote "that's at the maintainer's discretion" (ie: to close
the bug). Well, here, the whole of Debian is depending on this kind of
decision, so I don't agree that this decision is only at the discretion
of the maintainer.

Therefore, I'm tempted to raise this to the technical committee (putting
their list as Cc). Does anyone see a reason why I am mistaking here?

Cheers,

Thomas Goirand (zigo)


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/557cb7ed.3060...@debian.org

Re: oldoldstable on DDPO

[Paul Wise]

On Sun, Jun 14, 2015 at 1:36 AM, Christoph Berg wrote:

> over the past days, DDPO grew the ability to also show oldoldstable
> (aka squeeze) versions, mostly for the benefit of those working on
> squeeze-lts.

I added this post to DevNews and sent it to d-d-a.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caktje6hh3_ec8u+ys4rojf2n1yyah0gkcrhpeckbqoyxvq6...@mail.gmail.com

Re: Adding support for LZIP to dpkg, using that instead of xz, archive wide

[Paul Wise]

On Sun, Jun 14, 2015 at 7:08 AM, Thomas Goirand wrote:

> Reading these bugs, am I right that the archive already supports lzip
> for the orig.tar file?

AFAICT, there is no mention of .lz or lzip in the dak source code.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAKTje6FgOyHXEu70i1zHmAOD0Ty9wZo=aH-+WZsnrNN1rW8v=w...@mail.gmail.com

Re: Adding support for LZIP to dpkg, using that instead of xz, archive wide

[Guillem Jover]

Hi,

On Sun, 2015-06-14 at 01:08:29 +0200, Thomas Goirand wrote:
> On 06/13/2015 10:55 AM, Paul Wise wrote:
> > On Sat, Jun 13, 2015 at 4:23 PM, Thomas Goirand wrote:
> >> I've been using xz compression for a long time, but I see a big defect
> >> which is today pushing me to turn it off for the .orig.tar file. The
> >> issue is that depending on the version of xz-utils, it produces a
> >> different output.

Well if you want reproducible output, then use the same tool version.
That's the equivalent of expecting that using a different gcc version
will give you the same output.

As long as the bitstream is compatible with previous versions, I don't
see it as a problem, and I'd expect such changes to be beneficial,
because say, they might allow making the encoder faster, or compress
better, etc.

> >> We use "git archive" within the PKG OpenStack team to generate this
> >> tarball (which is more or less the same as pristine-tar, except we use
> >> upstream tags rather than a pristine-tar branch). The fact that xz
> >> produces a different result makes it not reproducible. As a
> >> consequence, it is very hard for us to use this system across
> >> distributions (ie: use that in both Debian and Ubuntu, or in Sid &
> >> Jessie). We need consistency.

If you generate it once, as part of the release process, why do you
need to generate it on different systems with different versions? And
how does that have anything to do with what gets packaged in Debian.
For Debian you only need to generate it once, why would you want to
generate it anew every time you build a new Debian revision instead
of just reusing the same tarball that is on the archive, if you don't
keep source tarball releases around?

> >> As a friend puts it:
> >> 
> >> "This is a fundamental problem/defect with xz. This (and a lot of
> >> other such defects, e.g. non-robustness of xz archives that easily
> >> lead to file corruption etc) are the reason that there is lzip (and
> >> which is why gnu.org has, on a technical basis, decided that lzip is
> >> official gzip-successor for gnu software releases when they come in
> >> tarballs).

TBH this smells like FUD. For example I've never heard of corruption in
.xz files due to non-robustness, I'd expect that corruption to come from
external forces, and that integrity would help or not detect it. In any
case .xz supports CRC32, CRC64 and SHA-256 for integrity checks, .lz only
supports CRC32. More over lzip was created to overcome limitations in the
.lzma format, .xz came later and fixed the limitations of the .lzma format
too.

(And I could probably switch dpkg-deb's .xz integrity check to CRC64,
given that's the xz-utils command-line tool default.)

Also many GNU projects do not release lzip tarballs, but do release bzip
or xz ones and there are very few that exclusively release lzip tarballs.
If that's the equivalent of bazaar being the official GNU VCS that most
of the GNU projects do not use, well…

Actually where is the gnu.org decision documented? I don't see it
neither in the GCS, the “Information for Maintainers of GNU Software”,
nor in the ftp.gnu.org site. And automake still defaults to dist-gz in
latest git.

  
  

> >> So it'd be super nice to have LZIP support in dpkg, and use that
> >> instead of xz, archive wide.
> >> 
> >> Your thoughts everyone? Is there any reason why we wouldn't do that?

Yes, replacing xz with lzip on .deb or .dsc packages does not make any
sense. Adding lzip support for source packages *might* make some sense, as
I pointed out in the bug report. But doing so does have a very high cost:

  


Whenever considering to add a new compressor, all surrounding tools need
to be modified to support it as well:

  
  

That's a non-zero amount of work and time, and that does not take into
account external tools and users. It would also not be usable until the
next stable release. Also notice that for example there are still tools
that do not support data.tar.xz in .deb, which has been the default for
a while, which should give you an idea of what it takes.

Adding a new compressor, that does not bring any significant benefit in
compression ratio, speed or container format, that is either not widely
used or widely available in many systems, just for the benefit of very
few packages that might be releasing as well in other formats, or that
can be easily recompressed, still does not seem worth it, no.

I've yet to see an actual convincing argument why this would be worth
the effort and trouble.

Also not to mention that I was the first to also consider .lz when we
evaluated adding .xz support in dpkg back in 2009.

  

> > It was already rejected by the dpkg 

Re: DEB_SIGN_KEYID vs DEBSIGN_KEYID

[Guillem Jover]

Hi!

On Sun, 2015-06-07 at 10:36:41 +0200, Harald Dunkel wrote:
> For devscripts you can define a variable "DEBSIGN_KEYID". For
> dpkg it is called "DEB_SIGN_KEYID". git-buildpackage doesn't
> support a keyid environment variable at all, as it seems. All
> ignore the default-key option set in .gnupg/gpg.conf .

The devscripts ones are only settable in the devscripts config file.
The dpkg one is an environment variable:

  

I don't think changing the behavior of dpkg-buildpackage to defer to
GnuPG's default-key would be a good idea. Using the changelog address
as the default value seems saner to me, as that should in principle
pick the correct key in most cases. Also changing this would probably
break far many setups, which I'm not looking forward to.

> Would it be possible to get a common line here?

I'd recommend adding support for DEB_SIGN_KEYID as an environment
variable in other tools. :)

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150614041206.gb10...@gaara.hadrons.org