pecl-gnupg has the following dependencies: DEPEND="app-crypt/gpgme <app-crypt/gnupg-2" With the current portage tree it's impossible to fulfill these dependencies. All versions of gpgme depend on >=gnupg-2. CCing grknight who was the last one to actively touch that package.
The current version simply doesn't work with gnupg-2. Activity has started up again in the upstream repo, but the promised support of gnupg-2 is uncertain until the next release
Yeah I saw the same, I just pinged the upstream developer to get a state. Question is what to do with it right now. In the current state it's broken, so it should be masked and lastrited if there's no fix available. However if we can expect a new version soon (or at least a git snapshot that works in a modern stack) that would of course be preferable.
@Brian: Can you say what exactly doesn't work with gpg 2? I did a brief test and basic functionality seems to work. The upstream bugs indicate test failures, but if this is just a "it basically works, but some of the less common features will fail" we may be better off with using RESTRICT="test".
So after further tests it seems to me this package mostly works with gnupg-2.1, it's just test failures due to unexpected outputs. I think we can commit an update that removes the restriction to gnupg 1 and has a RESTRICT="test" until upstream situation improves. Not ideal, but certainly better than having a broken package. Looking at the ebuild I also wondered about the patch that gets applied from files/1.3.2/01-large_file_system.patch I found no indication what it's supposed to do, there's bug #350018, but that doesn't have a lot of info either. If it's serving a purpose we should upstream it, if not drop it.
Created attachment 536044 [details] pecl-gnupg-1.4.0-r2.ebuild proposed ebuild, changes: 1. remove dependency restriction for gnupg 2. RESTRICT="test" as long as upstream tests fail 3. remove largefile patch with unclear purpose
If there are no objections I'd commit an updated ebuild with RESTRICT="test" and relaxed dependencies. While the situation is not ideal I think it's better to have something that works than the current broken state. At least all basic functionality still works with gpg 2. Ideally we can hope that we'll get a better upstream release soon. I'd leave the largefile patch in, it seems to be some 32 bit thing I can't test because I don't have an active 32 bit x86 machine any more.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c38e9c07638d7db84e8e98b3e999cefaf50745db commit c38e9c07638d7db84e8e98b3e999cefaf50745db Author: Hanno <hanno@gentoo.org> AuthorDate: 2018-07-16 09:03:59 +0000 Commit: Hanno <hanno@gentoo.org> CommitDate: 2018-07-16 09:03:59 +0000 dev-php/pecl-gnupg: Allow gnupg 2. The existing package is not installable due to conflicting dependencies. Basic functionality works with gnupg 2. Some tests fail, therefore restricting tests. Closes: https://bugs.gentoo.org/657048 Package-Manager: Portage-2.3.42, Repoman-2.3.9 dev-php/pecl-gnupg/pecl-gnupg-1.4.0-r2.ebuild | 33 +++++++++++++++++++++++++++ 1 file changed, 33 insertions(+)
