Re: Bug#897642: RFS: gpgme1.0/1.11.1-1~bpo9+1
On Sun, Sep 9, 2018 at 3:21 PM, Carsten Schoenert
> 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.
Roger Shimizu, GMT +9 Tokyo