Update gnupg formula to 2.2.17?

Is there anything I can do to help get the gnupg formula updated from 2.2.16_1 to 2.2.17? Is there a guide to updating Brew formula for new releases? Is there a reason it hasn’t been updated yet (incompatibility, or something like that)?

If someone can point me in the right direction, I’d be happy to help update it. I use brew to keep essential applications for security updated on some macs that are used to access sensitive data, want to support keeping gnupg’s formula updated.



There is a pull request for this change; further details about the holdup are on the PR: https://github.com/Homebrew/homebrew-core/pull/41780.

I can’t say for certain if my logic was completely worded correctly but it seems as though the problem originates from GPGME now requiring a QT build dependency whenever it should have been optional. Of course, if your build system has QT installed, then it requires GnuPG 2.2.17, unless you pass the parameter --disable-gpg-test. If it’s not passed, then the test programs are build during make and require GnuPG 2.2.17. So, if they would correct the GPGME build dependencies to include QT as optional with the stipulation of disabling GPG tests, then perhaps this wouldn’t fail the linkage test. Just a guess though.



It looks like the problem is a test in gnupg itself. If you remove “--enable-all-tests”, from the configure command at the bottom of gnupg.rb, that lets 2.2.17 install OK. So, focusing on gnupg, options I see:

  • remove “--enable-all-tests” from the configure line.
  • require qt as part of gnupg (this is overkill for my use, but not sure generally).
  • look into how to configure so it just skips test(s) that need(s) qt.

Do you think we need the “--enable-all-tests”?

This is possible. However, I would believe that since GnuPG is the actual tool for secure communications and GPGME is the interface then it would probably be better to disable some tests instead of every one. Here’s a copy/paste of ‘–disable-gpg-test’ from the link for building/installing GPGME.

The GPGME package is a C library that allows cryptography support to be added to a program. It is designed to make access to public key crypto engines like GnuPG or GpgSM easier for applications. GPGME provides a high-level crypto API for encryption, decryption, signing, signature verification and key management.

Installation of GPGME

Install GPGME by running the following commands:

./configure --prefix=/usr --disable-gpg-test && make

To test the results, you should have GnuPG-2.2.17 installed and remove the –disable-gpg-test above. Issue: make check .

Now, as the root user:

make install

Command Explanations

--disable-gpg-test : if this parameter is not passed to configure, the test programs are built during make stage, which requires GnuPG-2.2.17. This parameter is not needed if GnuPG-2.2.17 is installed.

If I understand correctly, the problem for this pull request is that GPGME is being run when the gnupg recipe is run, as part of the tests when it builds gnupg (this might be new on their part as of 2.2.17?), and GPGME requires QT, so the gnupg recipe is now breaking if you don’t have QT installed, because it includes GPGME in its tests and GPGME won’t build without QT.

So, this isn’t a problem, really, with GPGME, I think. If GPGME depends on gnupg, and we make it so gnupg installs ok, then that will work just fine when you try to separately install GPGME. The problem here looks to me like it is that tests for gnupg 2.2.17 include GPGME, which depends on QT, and so the install of gnupg is failing, while GPGME is trying to install its dependencies.

To fix this, if we just want the base gpg install to not test on GPGME, you’d need to know if there is a configure flag for gnupg to tell it to skip GPGME tests. If this exists, we could just set this flag in gnupg.rb and be done.

If that doesn’t exist, I guess you could go to the gnupg people and see if they would add one in. It would depend on how they have implemented their tests.

If there is no option in the base gnupg install to skip those GPGME tests, then, to just install gnupg, you are down to skipping all tests, requiring QT, or perhaps some other options I don’t know about because I am new to all this.

Make sense? Am I confused or missing something?

I’ll try to look into the configure options for gnupg later today, see if the option to skip GPGME tests (and so avoid needing QT for gnupg) is implemented.

I looked at the gnupg configure and I couldn’t find any flags for Disabling GPGME tests. I got confused in this post earlier and thought I’d found something to disable it, but that was for GPSM. Sorry for the confusion (was watching sick 3-year-old at the same time, a little distracted). So, nothing new to report here in terms of options for “configure.ac” (link to build_gpsm flag I mixed up with GPGME: gpg/gnupg/blob/master/configure.ac#L1812), and sorry for the confusion.

also, please let me know if details are better stored here or on the pull request.

Yep. My understanding of it’s a kind of catch-22 during the test phase for brew linking to GPGME, but the GPGME having QT bindings which aren’t installed. Probably more could be obtained if the Travis build log snapshot were available. Either way, the original submission should probably be closed, since it doesn’t seem to be having any progress and either reopen or resubmit by the OP. This would help to bring it to the attention of the maintainers since I don’t believe any one is wanting to chime in for assistance.

I’d say the info is better made available where the work is being done (in the PR)

OK. I moved a summary of what we’ve discussed over to the PR. Without any interaction with gnupg, I am not sure whether it is more secure to make sure you can run all the tests that gnupg thinks are important, and so you require qt, or if the tests are not actually essential for secure use of gnupg, and so you are OK to not “--enable-all-tests”.

Just letting you know that GnuPG 2.2.17 build/test fine now with the GPGME 1.13.1 formula. The PR I submitted reverted the dependencies back to those prior to the QT bindings and must have the been the problem. It wasn’t a version conflict and perhaps the bindings could be added back to GPGME. But, whomever changed it to add the QT, along with including other dependencies, didn’t do it correctly and most likely didn’t test it either. It was force pushed and hence this lengthy process of troubleshooting ensued.