Bug#897642: RFS: gpgme1.0/1.11.1-1~bpo9+1

[Carsten Schoenert]

[Reduced the CC list]

Hello Roger,

Am 20.09.18 um 02:53 schrieb Roger Shimizu:
> And I'm not the maintainer of src:gnupg2. I just want to help
> Bug#906545, and upstream maintainer says patching stable version may
> be hard and backport may be easier.
> 
> backports should be no harm since it uses ~bpo in version.
> So it's still feasible if pkg maintainer and release team decide to
> include a new major version into point release.

yes and no.
Technically it's no problem to provide gnupg2 through backports, the
downside is that users need to act here proactively and install this
package with some extra knowledge.

It's not that I'm against this, providing a package by backports is in
my eyes even better than providing nothing and pushing people to use
usptream releases directly (like enigmail e.g. for now).

...
> Did you report this situation to release team?
> I think if it's necessary and release team agree, gnupg2 maintainer
> can certainly help.

No, I haven't talked to the release team, I'm mostly in contact with the
security team by my involvement due the thunderbird package. And we did
have some conversation together with dkg as one of the maintainers of
enigmail and gnupg2. dkg has summarized the current problem with
enigmail and gnupg2 in #909000.

I'm the wrong person to make a judgment for doing a backport of gnupg2,
if ever one can something to this than this is Daniel or Eric. So in my
eyes it's better to ask the original package maintainer, maybe Daniel is
fine with an upload of gnupg2 to backports? And if yes it's probably
also o.k. then to upload a recent enigmail version to backports
afterwards. In the future it's later always possible to provide a newer
version through stable-security.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909000#15

-- 
Regards
Carsten Schoenert

Bug#897642: RFS: gpgme1.0/1.11.1-1~bpo9+1

[Roger Shimizu]

On Sun, Sep 9, 2018 at 3:21 PM, Carsten Schoenert
 wrote:
> Hi,
>
> Am 09.09.18 um 07:55 schrieb Roger Shimizu:
> ...
>> Both gpgme1.0 and libgpg-error are already in backports NEW queue.
>> So I'm closing this ticket.
>>
>>> Thank you>> Looking into why you did a gnupg2 backport I probably should use
>>> that too, to support newer ECC keys.>
>> Please do so.
>> Thanks for your work!
>
> please talk before doing a backport to the release team if they would
> accept in circumstances gnupgp2 within a point release, supporting
> recent gpg key material is something which can also being seen as a
> security fix, and that's the point releases are for, not backports.
> Given that Stretch is quite young in a possible lifespan of four years I
> bet gnupg2 will need at one for Stretch obviously.

And I'm not the maintainer of src:gnupg2. I just want to help
Bug#906545, and upstream maintainer says patching stable version may
be hard and backport may be easier.

backports should be no harm since it uses ~bpo in version.
So it's still feasible if pkg maintainer and release team decide to
include a new major version into point release.

> It's already (to?) late for enigmail e.g., Thunderbird 60.0 has a Breaks
> on Enigmail < 2 and enigmail will need gnupg2. Thunderbird 60.0 has
> taken the NEW queue for s-s a few days ago. Time is passing by ...
>
> So people can use the recent Enigmail extension from
> https://addons.thunderbird.net/ of course but don't get support for new
> keys I guess as s-s don't get a recent enigmail package which is
> requiring gnupg2.
>
> Note: I'm not that deep in the impact of an introduction of gnupg2, so I
> might have not a realistic view on this all. I just see that we once
> again have made our self a hard time with the release of a new ESR
> version of Thunderbird like for 45 and 52 in the past.

Did you report this situation to release team?
I think if it's necessary and release team agree, gnupg2 maintainer
can certainly help.

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#897642: RFS: gpgme1.0/1.11.1-1~bpo9+1

[Roger Shimizu]

[ Resend for the record with the lists below ]
+ debian-backports@l.d.o
+ pkg-gnupg-maint@l.alioth.d.o

On Sat, Sep 1, 2018 at 11:15 PM, Jacob Adams  wrote:
> control: tag -1 -moreinfo
>
> On Sep 1, 2018, at 04:49, Roger Shimizu  wrote:
>
> control: tag -1 +moreinfo
>
> Dear Jacob,
>
> On Fri, May 4, 2018 at 3:27 AM, Jacob Adams  wrote:
>
> Package: sponsorship-requests
>
> Severity: normal
>
>
>  Dear mentors,
>
>
>  I am looking for a sponsor for my package "gpgme1.0"
>
>
> Thanks for your interest in contribution to debian!
>
>  Changes since the last upload:
>
>
> gpgme1.0 (1.11.1-1~bpo9+1) stretch-backports; urgency=medium
>
>
>  * Rebuild for stretch-backports.
>
>
> -- Jacob Adams   Thu, 26 Apr 2018 13:13:54 -0400
>
>
>
> This package will also require libgpgerror, which you can find here:
>
>
> https://mentors.debian.net/package/libgpg-error
>
>
> https://mentors.debian.net/debian/pool/main/libg/libgpg-error/libgpg-error_1.29-4~bpo9+1.dsc
>
>
> It already has an RFS: #897045
>
>
> I would like to be able to use the latest version of GPGME in my GSoC
>
> 2018 project. In order to do that I would prefer to use a backport as
>
> the PGP Clean Room CD is based off of stretch.
>
>
> I see the project seems already released as beta [1], so maybe there's
> no need to do this backports upload?
>
>
> My project does require a newer version of GPGME than is shipped in stretch.
> However, I didn’t want to wait on the backport, so I’ve been including the
> deb files directly in my build:
> https://salsa.debian.org/tookmund-guest/make-pgp-clean-room/tree/master/resources/config/packages.chroot
>
>
> And what's the benefit for this backports pkg? Any new feature or
> bugfix you're particularly interested in?
>
>
> There has been significant improvement in GPGME’s python binding since
> stretch, and my project relies on these features, such as the new key
> generation function.
>
> It would be nice to be able to pull these packages from backports instead of
> including them directly.

I compiled this pkg under stretch, and meet the following error.


cJSON.c:45:20: fatal error: gpgrt.h: No such file or directory
 # include 
^


I see you updated libgpg-error to 1.29, so I tried to compile with
latest backported sid version, 1.32, and it succeeded.
So I updated D-B on libgpg-error to >= 1.29.

I uploaded this backported pkg to DELAYED/6.
So If you don't like the backports upload, just kindly cancel it.

Cheers,
--
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#897642: RFS: gpgme1.0/1.11.1-1~bpo9+1

[Jacob Adams]

> On Sep 1, 2018, at 12:45, Roger Shimizu  wrote:
> 
> I compiled this pkg under stretch, and meet the following error.
> 
> 
> cJSON.c:45:20: fatal error: gpgrt.h: No such file or directory
> # include 
>^
> 
> 
> I see you updated libgpg-error to 1.29, so I tried to compile with
> latest backported sid version, 1.32, and it succeeded.
> So I updated D-B on libgpg-error to >= 1.29.
> 

Should’ve mentioned that it required a newer version of libgpg-error sorry. 
Thanks for fixing that and updating the backport. 

> I uploaded this backported pkg to DELAYED=6.
> So If you don't like the backports upload, just kindly cancel it.
> 

Thank you!
Looking into why you did a gnupg2 backport I probably should use that too, to 
support newer ECC keys.

Thanks again,
Jacob

Bug#897642: RFS: gpgme1.0/1.11.1-1~bpo9+1

[Roger Shimizu]

On Sat, Sep 1, 2018 at 11:15 PM, Jacob Adams  wrote:
> control: tag -1 -moreinfo
>
> On Sep 1, 2018, at 04:49, Roger Shimizu  wrote:
>
> control: tag -1 +moreinfo
>
> Dear Jacob,
>
> On Fri, May 4, 2018 at 3:27 AM, Jacob Adams  wrote:
>
> Package: sponsorship-requests
>
> Severity: normal
>
>
>  Dear mentors,
>
>
>  I am looking for a sponsor for my package "gpgme1.0"
>
>
> Thanks for your interest in contribution to debian!
>
>  Changes since the last upload:
>
>
> gpgme1.0 (1.11.1-1~bpo9+1) stretch-backports; urgency=medium
>
>
>  * Rebuild for stretch-backports.
>
>
> -- Jacob Adams   Thu, 26 Apr 2018 13:13:54 -0400
>
>
>
> This package will also require libgpgerror, which you can find here:
>
>
> https://mentors.debian.net/package/libgpg-error
>
>
> https://mentors.debian.net/debian/pool/main/libg/libgpg-error/libgpg-error_1.29-4~bpo9+1.dsc
>
>
> It already has an RFS: #897045
>
>
> I would like to be able to use the latest version of GPGME in my GSoC
>
> 2018 project. In order to do that I would prefer to use a backport as
>
> the PGP Clean Room CD is based off of stretch.
>
>
> I see the project seems already released as beta [1], so maybe there's
> no need to do this backports upload?
>
>
> My project does require a newer version of GPGME than is shipped in stretch.
> However, I didn’t want to wait on the backport, so I’ve been including the
> deb files directly in my build:
> https://salsa.debian.org/tookmund-guest/make-pgp-clean-room/tree/master/resources/config/packages.chroot
>
>
> And what's the benefit for this backports pkg? Any new feature or
> bugfix you're particularly interested in?
>
>
> There has been significant improvement in GPGME’s python binding since
> stretch, and my project relies on these features, such as the new key
> generation function.
>
> It would be nice to be able to pull these packages from backports instead of
> including them directly.

I compiled this pkg under stretch, and meet the following error.


cJSON.c:45:20: fatal error: gpgrt.h: No such file or directory
 # include 
^


I see you updated libgpg-error to 1.29, so I tried to compile with
latest backported sid version, 1.32, and it succeeded.
So I updated D-B on libgpg-error to >= 1.29.

I uploaded this backported pkg to DELAYED=6.
So If you don't like the backports upload, just kindly cancel it.

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#897642: RFS: gpgme1.0/1.11.1-1~bpo9+1

[Jacob Adams]

control: tag -1 -moreinfo

> On Sep 1, 2018, at 04:49, Roger Shimizu  wrote:
> 
> control: tag -1 +moreinfo
> 
> Dear Jacob,
> 
>> On Fri, May 4, 2018 at 3:27 AM, Jacob Adams  wrote:
>> Package: sponsorship-requests
>> Severity: normal
>> 
>>  Dear mentors,
>> 
>>  I am looking for a sponsor for my package "gpgme1.0"
> 
> Thanks for your interest in contribution to debian!
> 
>>  Changes since the last upload:
>> 
>> gpgme1.0 (1.11.1-1~bpo9+1) stretch-backports; urgency=medium
>> 
>>  * Rebuild for stretch-backports.
>> 
>> -- Jacob Adams   Thu, 26 Apr 2018 13:13:54 -0400
>> 
>> 
>> This package will also require libgpgerror, which you can find here:
>> 
>> https://mentors.debian.net/package/libgpg-error
>> 
>> https://mentors.debian.net/debian/pool/main/libg/libgpg-error/libgpg-error_1.29-4~bpo9+1.dsc
>> 
>> It already has an RFS: #897045
>> 
>> I would like to be able to use the latest version of GPGME in my GSoC
>> 2018 project. In order to do that I would prefer to use a backport as
>> the PGP Clean Room CD is based off of stretch.
> 
> I see the project seems already released as beta [1], so maybe there's
> no need to do this backports upload?

My project does require a newer version of GPGME than is shipped in stretch. 
However, I didn’t want to wait on the backport, so I’ve been including the deb 
files directly in my build:
https://salsa.debian.org/tookmund-guest/make-pgp-clean-room/tree/master/resources/config/packages.chroot

> 
> And what's the benefit for this backports pkg? Any new feature or
> bugfix you're particularly interested in?

There has been significant improvement in GPGME’s python binding since stretch, 
and my project relies on these features, such as the new key generation 
function. 

It would be nice to be able to pull these packages from backports instead of 
including them directly. 

Thanks,
Jacob

Bug#897642: RFS: gpgme1.0/1.11.1-1~bpo9+1

[Roger Shimizu]

control: tag -1 +moreinfo

Dear Jacob,

On Fri, May 4, 2018 at 3:27 AM, Jacob Adams  wrote:
> Package: sponsorship-requests
> Severity: normal
>
>   Dear mentors,
>
>   I am looking for a sponsor for my package "gpgme1.0"

Thanks for your interest in contribution to debian!

>   Changes since the last upload:
>
> gpgme1.0 (1.11.1-1~bpo9+1) stretch-backports; urgency=medium
>
>   * Rebuild for stretch-backports.
>
>  -- Jacob Adams   Thu, 26 Apr 2018 13:13:54 -0400
>
>
> This package will also require libgpgerror, which you can find here:
>
> https://mentors.debian.net/package/libgpg-error
>
> https://mentors.debian.net/debian/pool/main/libg/libgpg-error/libgpg-error_1.29-4~bpo9+1.dsc
>
> It already has an RFS: #897045
>
> I would like to be able to use the latest version of GPGME in my GSoC
> 2018 project. In order to do that I would prefer to use a backport as
> the PGP Clean Room CD is based off of stretch.

I see the project seems already released as beta [1], so maybe there's
no need to do this backports upload?

And what's the benefit for this backports pkg? Any new feature or
bugfix you're particularly interested in?

BTW. I just uploaded gnupg 2.2 to stretch-backports, to fix #906545
[2]. And I see your RFS.

[1] https://tookmund.com/2018/07/pgp-clean-room-beta
[2] https://bugs.debian.org/906545

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#897642: RFS: gpgme1.0/1.11.1-1~bpo9+1

[Jacob Adams]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "gpgme1.0"

 * Package name: gpgme1.0
   Version : 1.11.1-1~bpo9+1
   Upstream Author : GnuPG developers 
 * URL : https://gnupg.org/software/gpgme/index.html
 * License : LGPL-2.1+
   Section : libs

  It builds those binary packages:

 libgpgme-dev - GPGME - GnuPG Made Easy (development files)
 libgpgme11 - GPGME - GnuPG Made Easy (library)
 libgpgmepp-dev - C++ and Qt bindings for GPGME (development files)
 libgpgmepp-doc - C++ and Qt bindings for GPGME (documentation for
developers)
 libgpgmepp6 - C++ wrapper library for GPGME
 libqgpgme7 - library for GPGME integration with Qt
 python-gpg - Python interface to the GPGME GnuPG encryption library
(Python 2)
 python3-gpg - Python interface to the GPGME GnuPG encryption library
(Python 3)

  To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/gpgme1.0


  Alternatively, one can download the package with dget using this command:

dget -x
https://mentors.debian.net/debian/pool/main/g/gpgme1.0/gpgme1.0_1.11.1-1~bpo9+1.dsc


  Changes since the last upload:

gpgme1.0 (1.11.1-1~bpo9+1) stretch-backports; urgency=medium

  * Rebuild for stretch-backports.

 -- Jacob Adams   Thu, 26 Apr 2018 13:13:54 -0400


This package will also require libgpgerror, which you can find here:

https://mentors.debian.net/package/libgpg-error

https://mentors.debian.net/debian/pool/main/libg/libgpg-error/libgpg-error_1.29-4~bpo9+1.dsc

It already has an RFS: #897045

I would like to be able to use the latest version of GPGME in my GSoC
2018 project. In order to do that I would prefer to use a backport as
the PGP Clean Room CD is based off of stretch.

Thanks,
Jacob



signature.asc
Description: OpenPGP digital signature