On Tue, Sep 3, 2013 at 15:06:14 +0200, Daniel Leidert wrote: > please try to CC 710...@bugs.debian.org in your response > > Am Sonntag, den 25.08.2013, 12:19 +0200 schrieb Francesco Poli: > > > is anyone working on bug #710140 ? > > Is there any progress? > > Well, there was only libgpgme++2 affected by this upstream change and > this package has seen two uploads since its own dropping of libgpgme > ++-pth.so.2, which was the only binary/library linking to libgpgme-pth > inside Debian. I haven't seen any report [1], that there is still an > affected package(?). > > > Could you please clarify the status of the bug? > > Thanks for your time! > > CCing release.d.o. > > Here is what upstream said about this change: > > "Remove support for libgpgme-pth. As far as we know, this was never > used, and GnuPG is going to use our own npth in the future." [2] > > Inside Debian I didn't find any reference to the usage of libgpgme-pth > except for libgpgme++2, which provided the libgpgme++-pth.so.2 wrapper > library, which itself wasn't used by any other Debian package (AFAIK). > > I'm hereby asking the release team how to proceed? The issue itself > seems to have been fixed inside Debian by fixing libgpgme++2, which has > already been done [3]. There might be third-party software out there > using libgpgme-pth.so or libgpgme++-pth.so. However, I don't know about > it; upstream doesn't know about it either (that's why they dropped it I > guess) and I haven't seen any comment on this change neither on the > gnupg list nor inside #710140 nor for libgpgme++2. > > I see two ways: (a) start a proper transition; (b) stay with the current > solution and wait if someone reports an issue with it. Note, that the > affected gpgme version has already hit testing (the issue was discovered > late). > I think if you're confident nothing in Debian ever used that library then (b) is good enough.
Cheers, Julien
signature.asc
Description: Digital signature
