On 03/16/2012 09:21 AM, Gaetan Bisson wrote:
> Hi guys,
>
> On FS [1], Tom suggested to make gpgme depend on just one of gnupg and
> gnupg2, and I further argued that we do not need two versions of gnupg
> in our repos.
>
> I propose to:
> - Upgrade gnupg to upstream latest stable, that is version 2.0.
> - Symlink /usr/bin/gpg to /usr/bin/gpg2 for backward compatibility.
> - Remove the gnupg2 package from our repos.
>
> See [2] for an updated gnupg PKGBUILD.
>
> I have been running these changes on my system for months with no issue.
> There have been rumors of problems [3], but as far I can tell it's FUD:
> nobody ever reported a concrete issue.
>
> I'm bringing this up here at Andreas' request: any opinions?
>
> [1] https://bugs.archlinux.org/task/28931
> [2] http://paste.xinu.at/Gji/
> [3] https://bugs.archlinux.org/task/22110
>

my key holder card doesn't work with gpg2

gpg2 --card-status
gpg: selecting openpgp failed: Unsupported certificate
gpg: OpenPGP card not available: Unsupported certificate

I think is because I used gpg1 when I generated the key

--
IonuÈ›

[2012-03-16 10:07:03 +0200] Ionut Biru:
> gpg2 --card-status
> gpg: selecting openpgp failed: Unsupported certificate
> gpg: OpenPGP card not available: Unsupported certificate
>
> I think is because I used gpg1 when I generated the key

If I google those error messages, I find different answers. Have you
looked at these? It would be a real shame to stick with gnupg-1 only for
this reason. And I thought those cards were supposed to be supported by
GPG devs...

--
Gaetan

Am 16.03.2012 10:18, schrieb Gaetan Bisson:
> [2012-03-16 10:07:03 +0200] Ionut Biru:
>> gpg2 --card-status
>> gpg: selecting openpgp failed: Unsupported certificate
>> gpg: OpenPGP card not available: Unsupported certificate
>>
>> I think is because I used gpg1 when I generated the key
>
> If I google those error messages, I find different answers. Have you
> looked at these? It would be a real shame to stick with gnupg-1 only for
> this reason. And I thought those cards were supposed to be supported by
> GPG devs...

I think mine worked fine with both gpg and gpg2, but I don't remember.

On 03/16/2012 11:18 AM, Gaetan Bisson wrote:
> [2012-03-16 10:07:03 +0200] Ionut Biru:
>> gpg2 --card-status
>> gpg: selecting openpgp failed: Unsupported certificate
>> gpg: OpenPGP card not available: Unsupported certificate
>>
>> I think is because I used gpg1 when I generated the key
>
> If I google those error messages, I find different answers. Have you
> looked at these? It would be a real shame to stick with gnupg-1 only for
> this reason. And I thought those cards were supposed to be supported by
> GPG devs...
>

found it.
http://www.opensc-project.org/opensc/wiki/OpenPGP
Linux (and Gnome)

I had to unset GPG_AGENT. WTF


--
IonuÈ›

Am 16.03.2012 10:54, schrieb Ionut Biru:
> On 03/16/2012 11:18 AM, Gaetan Bisson wrote:
>> [2012-03-16 10:07:03 +0200] Ionut Biru:
>>> gpg2 --card-status
>>> gpg: selecting openpgp failed: Unsupported certificate
>>> gpg: OpenPGP card not available: Unsupported certificate
>>>
>>> I think is because I used gpg1 when I generated the key
>>
>> If I google those error messages, I find different answers. Have you
>> looked at these? It would be a real shame to stick with gnupg-1 only for
>> this reason. And I thought those cards were supposed to be supported by
>> GPG devs...
>>
>
> found it.
> http://www.opensc-project.org/opensc/wiki/OpenPGP
> Linux (and Gnome)
>
> I had to unset GPG_AGENT. WTF

That sounds like a problem we should try to solve after we make the
transition, as it sounds like it might be related to having two
different gnupg implementations that potentially conflict.

On Fri, Mar 16, 2012 at 5:06 AM, Thomas Bächler <thomas@archlinux.org> wrote:
> Am 16.03.2012 10:54, schrieb Ionut Biru:
>> On 03/16/2012 11:18 AM, Gaetan Bisson wrote:
>>> [2012-03-16 10:07:03 +0200] Ionut Biru:
>>>> *gpg2 --card-status
>>>> gpg: selecting openpgp failed: Unsupported certificate
>>>> gpg: OpenPGP card not available: Unsupported certificate
>>>>
>>>> I think is because I used gpg1 when I generated the key
>>>
>>> If I google those error messages, I find different answers. Have you
>>> looked at these? It would be a real shame to stick with gnupg-1 only for
>>> this reason. And I thought those cards were supposed to be supported by
>>> GPG devs...
>>>
>>
>> found it.
>> http://www.opensc-project.org/opensc/wiki/OpenPGP
>> Linux (and Gnome)
>>
>> I had to unset GPG_AGENT. WTF
>
> That sounds like a problem we should try to solve after we make the
> transition, as it sounds like it might be related to having two
> different gnupg implementations that potentially conflict.

I have gpg and gpg2 installed but have been exclusively using gpg2 for
both my card and normal private keys without issue. I'm definitely in
support of dropping gpg1.

However, calling it an "old branch" is a bit of a misnomer, as
upstream just released a version of it in the last month or so. 1.4 vs
2.x have very different architectures and 2.x is much more
componentized.

-Dan

On 16/03/12 17:21, Gaetan Bisson wrote:
> Hi guys,
>
> On FS [1], Tom suggested to make gpgme depend on just one of gnupg and
> gnupg2, and I further argued that we do not need two versions of gnupg
> in our repos.
>
> I propose to:
> - Upgrade gnupg to upstream latest stable, that is version 2.0.
> - Symlink /usr/bin/gpg to /usr/bin/gpg2 for backward compatibility.
> - Remove the gnupg2 package from our repos.
>
> See [2] for an updated gnupg PKGBUILD.
>
> I have been running these changes on my system for months with no issue.
> There have been rumors of problems [3], but as far I can tell it's FUD:
> nobody ever reported a concrete issue.
>
> I'm bringing this up here at Andreas' request: any opinions?
>
> [1] https://bugs.archlinux.org/task/28931
> [2] http://paste.xinu.at/Gji/
> [3] https://bugs.archlinux.org/task/22110


I would much prefer dropping gnupg2 as a dependency of gpgme.

It would remove at least the following packages from [core]:
dirmngr
libassuan
libgpg-error
libksba
pinentry
pth


From the gpg download page:

"Please read the NEWS file for a more complete list. 1.4.12 is the
stable version of GnuPG. (2.0.18 is the unstable development version)."

So we would be making our package manager rely on something that
upstream considers an _unstable development version_. That just seems
stupid even for a bleeding edge distro.


Now... has anyone proposing this actually done the work and noted which
configure options get disabled when building gpgme against only one of
gnupg or gnupg2. I remember there was differences when I was looking
into this for the same request made back in 2010
(https://bugs.archlinux.org/task/22110). I can not remember the
results, but I remember there was a difference.

Allan

On Sun, Mar 18, 2012 at 8:00 AM, Allan McRae <allan@archlinux.org> wrote:
> Now... *has anyone proposing this actually done the work and noted which
> configure options get disabled when building gpgme against only one of
> gnupg or gnupg2. *I remember there was differences when I was looking
> into this for the same request made back in 2010
> (https://bugs.archlinux.org/task/22110). *I can not remember the
> results, but I remember there was a difference.

I tried building it only against gnupg2, and as far as I could tell it
made no difference. If I understood correctly building against gnupg1
means that we don't get support for gpgms (at least).

Dropping gnupg2 does not sound like a good idea, as that means people
would have to build a second verision of gpgme to get gnupg2 features.
Furthermore, if we drop gnupg1, we could eventually drop it from the
repos all together, which would not be the case for gnup2 as it has
more features people might need.

As to the stability, I don't know much about this. It seems that
upstream needs to clarify their communication, in the release
announcement of 2.0.18 they refer to it as "stable" and make no
suggestions that version 1 should be better in this regard:

"We are pleased to announce the availability of a new stable GnuPG-2
release: Version 2.0.18.

[...]

GnuPG-2 has a different architecture than GnuPG-1 (e.g. 1.4.11) in
that it splits up functionality into several modules. However, both
versions may be installed alongside without any conflict. In fact,
the gpg version from GnuPG-1 is able to make use of the gpg-agent as
included in GnuPG-2 and allows for seamless passphrase caching. The
advantage of GnuPG-1 is its smaller size and the lack of dependency on
other modules at run and build time. We will keep maintaining GnuPG-1
versions because they are very useful for small systems and for server
based applications requiring only OpenPGP support."

Cheers,

Tom

On 18/03/12 22:08, Tom Gundersen wrote:
> On Sun, Mar 18, 2012 at 8:00 AM, Allan McRae <allan@archlinux.org> wrote:
>> Now... has anyone proposing this actually done the work and noted which
>> configure options get disabled when building gpgme against only one of
>> gnupg or gnupg2. I remember there was differences when I was looking
>> into this for the same request made back in 2010
>> (https://bugs.archlinux.org/task/22110). I can not remember the
>> results, but I remember there was a difference.
>
> I tried building it only against gnupg2, and as far as I could tell it
> made no difference. If I understood correctly building against gnupg1
> means that we don't get support for gpgms (at least).
>
> Dropping gnupg2 does not sound like a good idea, as that means people
> would have to build a second verision of gpgme to get gnupg2 features.

I believe you can use make/optdepends there...

> Furthermore, if we drop gnupg1, we could eventually drop it from the
> repos all together, which would not be the case for gnup2 as it has
> more features people might need.

I think thet gnupg1 is more suited to what _ALL_ Arch systems use gpgme
for. The simple verification of package signatures.

Allan

[2012-03-19 08:20:34 +1000] Allan McRae:
> I think thet gnupg1 is more suited to what _ALL_ Arch systems use gpgme
> for. The simple verification of package signatures.

Well, linux-2.6.27.62 would also be sufficient to run Arch. But we only
package modern stable upstream releases, and certain users actually make
use of their modern features.

--
Gaetan