[bug#29781] GnuPG 2.0 end-of-life

[bug#29781] GnuPG 2.0 end-of-life

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 339 bytes --]

The 2.0 series of GnuPG will stop receiving upstream support at the the
end of the year:

"GnuPG 2.0 is an older branch of GnuPG. This branch will reach end-of-life on
2017-12-31." [0]

These patches adjust the two packages that use gnupg-2.0 to prepare for removing
or deprecating that package.

[0] https://gnupg.org/download/index.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[bug#29781] [PATCH 1/2] gnu: gpgme: Build with the latest GnuPG.

[Leo Famulari]

* gnu/packages/gnupg.scm (gpgme)[inputs]: Use the latest gnupg and make
it a native-input.
---
 gnu/packages/gnupg.scm | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/gnupg.scm b/gnu/packages/gnupg.scm
index 336cd8f74..b485ac9af 100644
--- a/gnu/packages/gnupg.scm
+++ b/gnu/packages/gnupg.scm
@@ -380,12 +380,13 @@ libskba (working with X.509 certificates and CMS data).")
        (base32
         "1ssc0gs02r4fasabk7c6v6r865k2j02mpb5g1vkpbmzsigdzwa8v"))))
     (build-system gnu-build-system)
+    (native-inputs
+     `(("gnupg" ,gnupg)))
     (propagated-inputs
      ;; Needs to be propagated because gpgme.h includes gpg-error.h.
      `(("libgpg-error" ,libgpg-error)))
     (inputs
-     `(("gnupg" ,gnupg-2.0)
-       ("libassuan" ,libassuan)))
+     `(("libassuan" ,libassuan)))
     (arguments
      `(#:phases
        (modify-phases %standard-phases
-- 
2.15.1

[bug#29781] [PATCH 2/2] gnu: python-pygpgme: Use GnuPG 1 for the test suite.

[Leo Famulari]

* gnu/packages/gnupg.scm (python-pygpgme, python2-pygpgme)[inputs]: Use gnupg-1
and make it a native-input.
---
 gnu/packages/gnupg.scm | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/gnupg.scm b/gnu/packages/gnupg.scm
index b485ac9af..c0142fa9f 100644
--- a/gnu/packages/gnupg.scm
+++ b/gnu/packages/gnupg.scm
@@ -492,9 +492,10 @@ distributed separately.")
            (lambda _
              (zero? (system* "make" "check")))))))
     (build-system python-build-system)
+    (native-inputs
+     `(("gnupg" ,gnupg-1)))
     (inputs
-     `(("gnupg" ,gnupg-2.0)
-       ("gpgme" ,gpgme)))
+     `(("gpgme" ,gpgme)))
     (home-page "https://launchpad.net/pygpgme")
     (synopsis "Python module for working with OpenPGP messages")
     (description
-- 
2.15.1

[bug#29781] [PATCH 2/2] gnu: python-pygpgme: Use GnuPG 1 for the test suite.

[Ludovic Courtès]

Leo Famulari <leo@famulari.name> skribis:

> * gnu/packages/gnupg.scm (python-pygpgme, python2-pygpgme)[inputs]: Use gnupg-1
> and make it a native-input.

LGTM!

BTW, gpgme itself provides Python bindings, which are recommended, I
think.  Should we build them?

Ludo’.

bug#29781: [PATCH 2/2] gnu: python-pygpgme: Use GnuPG 1 for the test suite.

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 878 bytes --]

On Wed, Dec 20, 2017 at 02:29:02PM +0100, Ludovic Courtès wrote:
> Leo Famulari <leo@famulari.name> skribis:
> 
> > * gnu/packages/gnupg.scm (python-pygpgme, python2-pygpgme)[inputs]: Use gnupg-1
> > and make it a native-input.
> 
> LGTM!
> 
> BTW, gpgme itself provides Python bindings, which are recommended, I
> think.  Should we build them?

We package them as python-gpg.

However, this PyPi-based package seems to be abandoned by the GPGME
maintainers. At least, it doesn't get updated regularly.

I've been trying to build the bindings as part of the GPGME build, so
that we can get the latest version, but I haven't had time to finish the
work yet.

Once we are able to build the bindings from the latest GPGME, we will be
able to drop the pygpgme package and just use the GPGME bindings for
the package 'alot', which is the only user of pygpgme.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[bug#29781] [PATCH 2/2] gnu: python-pygpgme: Use GnuPG 1 for the test suite.

[Ludovic Courtès]

Leo Famulari <leo@famulari.name> skribis:

> On Wed, Dec 20, 2017 at 02:29:02PM +0100, Ludovic Courtès wrote:
>> Leo Famulari <leo@famulari.name> skribis:
>> 
>> > * gnu/packages/gnupg.scm (python-pygpgme, python2-pygpgme)[inputs]: Use gnupg-1
>> > and make it a native-input.
>> 
>> LGTM!
>> 
>> BTW, gpgme itself provides Python bindings, which are recommended, I
>> think.  Should we build them?
>
> We package them as python-gpg.
>
> However, this PyPi-based package seems to be abandoned by the GPGME
> maintainers. At least, it doesn't get updated regularly.
>
> I've been trying to build the bindings as part of the GPGME build, so
> that we can get the latest version, but I haven't had time to finish the
> work yet.
>
> Once we are able to build the bindings from the latest GPGME, we will be
> able to drop the pygpgme package and just use the GPGME bindings for
> the package 'alot', which is the only user of pygpgme.

OK, sounds good.  Thanks for explaining!

Ludo’.

[bug#29781] [PATCH 1/2] gnu: gpgme: Build with the latest GnuPG.

[Ludovic Courtès]

Leo Famulari <leo@famulari.name> skribis:

> * gnu/packages/gnupg.scm (gpgme)[inputs]: Use the latest gnupg and make
> it a native-input.

I’m surprised gpgme doesn’t retain a reference to gpg.

Apparently, ‘dirinfo.gpg_name’ in src/dirinfo.c contains the file name
of the ‘gpg’ executable.

I can’t find what its default value is, but I think we should be
recording the absolute file name of ‘gpg’ as the default value.

Thoughts?

Ludo’.

[bug#29781] [PATCH 1/2] gnu: gpgme: Build with the latest GnuPG.

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 675 bytes --]

On Wed, Dec 20, 2017 at 02:28:01PM +0100, Ludovic Courtès wrote:
> Leo Famulari <leo@famulari.name> skribis:
> 
> > * gnu/packages/gnupg.scm (gpgme)[inputs]: Use the latest gnupg and make
> > it a native-input.
> 
> I’m surprised gpgme doesn’t retain a reference to gpg.
> 
> Apparently, ‘dirinfo.gpg_name’ in src/dirinfo.c contains the file name
> of the ‘gpg’ executable.
> 
> I can’t find what its default value is, but I think we should be
> recording the absolute file name of ‘gpg’ as the default value.
> 
> Thoughts?

Good point. I pushed 0e06bec250f which uses the latest GnuPG package and
makes GPGME use that particular GnuPG.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[bug#29781] [PATCH 1/2] gnu: gpgme: Build with the latest GnuPG.

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 1273 bytes --]

On Wed, Dec 20, 2017 at 04:43:13PM -0500, Leo Famulari wrote:
> On Wed, Dec 20, 2017 at 02:28:01PM +0100, Ludovic Courtès wrote:
> > Leo Famulari <leo@famulari.name> skribis:
> > 
> > > * gnu/packages/gnupg.scm (gpgme)[inputs]: Use the latest gnupg and make
> > > it a native-input.
> > 
> > I’m surprised gpgme doesn’t retain a reference to gpg.
> > 
> > Apparently, ‘dirinfo.gpg_name’ in src/dirinfo.c contains the file name
> > of the ‘gpg’ executable.
> > 
> > I can’t find what its default value is, but I think we should be
> > recording the absolute file name of ‘gpg’ as the default value.
> > 
> > Thoughts?
> 
> Good point. I pushed 0e06bec250f which uses the latest GnuPG package and
> makes GPGME use that particular GnuPG.

Due to breakage of python-pygpgme, which does not support GnuPG > 2.0, I
reverted the part of that commit which binds GPGME with the GnuPG used
during building in commit b3ecb3fe8d4:

https://lists.gnu.org/archive/html/guix-devel/2017-12/msg00371.html

I think this is okay. I use GPGME heavily for Mutt's PGP integration,
and it works fine for GPGME to find GnuPG in the environment.

Maybe once we are building the latest version of GPGME's Python bindings
we can undo the reversion.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]