Build fails on Gentoo for GpgFrontend 2.1.9: very new GpgMe 2.0.0 required instead of stable 1.24.3

[mattemod]

Hello,
I'm no CMake expert, so either I don't understand how to build GpgFrontend or there are problems with the default build config.
I'm trying to build on my Gentoo machine and in the end I'd like to create a working ebuild that I want to commit to Gentoo's Portage.
I looked for build instructions from you but didn't find any: did I miss them? Can you link them?

1. With info I found both here and somewhere else, I understood that I needed to do this to build: mkdir build-dir && cd build-dir/ && cmake -DCMAKE_BUILD_TYPE=Release -DGPGFRONTEND_BUILD_MODULES=OFF ..
2. I installed dev-cpp/gtest to solve this CMake Error: Could NOT find GTest (missing: GTEST_LIBRARY GTEST_INCLUDE_DIR GTEST_MAIN_LIBRARY). This allowed to create build files: Build files have been written to: /home/_shared/tools/GpgFrontend-2.1.9/build-dir.
3. So I simply launched make, but it fails with these errors in src/core/function/SecureRandomGenerator.cpp:

   ‘GPGME_RANDOM_MODE_NORMAL’ was not declared in this scope; did you mean ‘GPGME_SIG_MODE_NORMAL’?
   ‘GPGME_RANDOM_MODE_ZBASE32’ was not declared in this scope
   ‘gpgme_op_random_bytes’ was not declared in this scope
   

   However, app-crypt/gpgme is installed:
   app-crypt/gpgme-1.24.3:1/11.6.15.2::gentoo USE="cxx qt5 qt6 verify-sig -common-lisp -debug -python -static-libs -test" PYTHON_TARGETS="python3_13 -python3_11 -python3_12 (-python3_14)"

Can you help me understand the problem(s) and/or how to correctly build it?

Thanks
Kind regards

[mattemod]

I'll give some context/information for those who don't know Gentoo: packages are built from source by Portage (its package manager); they each have their own USE flags that determine which functionalities are built.
In my app-crypt/gpgme's case, the active ones are cxx qt5 qt6 verify-sig and Python 3.13 support, while all the others are deactivated.
Here's an explanation of those USE flags by equery uses app-crypt/gpgme:

 - - common-lisp               : Install common-lisp files
 + + cxx                       : Build support for C++ (bindings, extra libraries, code generation, ...)
 - - debug                     : Enable extra debug codepaths, like asserts and extra output. If you want to get meaningful backtraces see https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces
 - - python                    : Add optional support/bindings for the Python language
 - - python_targets_python3_11 : Build with Python 3.11
 - - python_targets_python3_12 : Build with Python 3.12
 + + python_targets_python3_13 : Build with Python 3.13
 + + qt5                       : Add support for the Qt 5 application and UI framework
 + + qt6                       : Add support for the Qt 6 application and UI framework
 - - static-libs               : Build static versions of dynamic libraries as well
 - - test                      : Enable dependencies and/or preparations necessary to run tests (usually controlled by FEATURES=test but can be toggled independently)
 + + verify-sig                : Verify upstream signatures on distfiles

[mattemod]

Ah, I think I found the problem: in the System Requirements (https://www.gpgfrontend.bktus.com/appendix/system-requirement/) you don't mention GpgMe's version, so one would assume it's a stable version (1.24.3), however GPGME_RANDOM_MODE_NORMAL is available only since GpgMe 2.0.0, which was released on 2025-06-03: https://github.com/gpg/gpgme/blob/cf41c8085b7414b9bdc03e0f68f2dfde3ced2b16/NEWS#L45

Is there a reason why you chose newly-released 2.0.0 instead of stable 1.24.3 ?

'cause I think it's a bit too recent to build against: most distros won't support that package as stable for a while, which means you'll need to support 1.24.3 if you want a wider adoption for GpgFrontend.

[saturneric]

Due to the need to support new features—such as leveraging GPG’s random number generator and, more importantly, allowing explicit subkey selection when signing — GpgFrontend now requires gpgme 2.0.0 or newer.

As you have noticed, most distributions do not yet provide gpgme 2.0.0 in their package repositories. To address this, I have introduced a CMake option: GPGFRONTEND_LINK_GPGME_INTO_CORE。On Linux, enabling this option will automatically build the latest gpgme (and its dependencies) as part of the build process. Furthermore, gpgme will be statically linked into the gf_core library, ensuring that GpgFrontend always uses the correct version regardless of the system libraries.

Refer: https://www.gpgfrontend.bktus.com/appendix/setup-dev-env/#configure-and-build-the-project

If this approach turns out to be incompatible with Gentoo Portage packaging guidelines, I can consider introducing a new build option to allow GpgFrontend to depend on gpgme 1.24.3 again (as provided in Gentoo), while disabling the new features that require gpgme 2.0.0.

[saturneric]

By the way, https://www.gpgfrontend.bktus.com/appendix/system-requirement/ is intended for end users. That’s why I haven’t listed all the build dependencies or packaging-related details there. :)

[mattemod]

OK, thank you for your prompt reply :)
Gentoo actually already provides packages for GpgMe 2.0.0 but they are currently heavy-masked, probably because they need a lot more testing, being it a major version update in which I think they split it upstream in multiple packages.

With that said, I just tried adding -DGPGFRONTEND_LINK_GPGME_INTO_CORE=ON but fails saying that third_party/libgpg-error is empty: I'll fix it later and let you know how it goes.

[mattemod]

Actually I had time to do it now: I put the source of the 3 deps (libgpg-error, libassuan, gpgme), this time tried compiling with Ninja, got to the end and generated a working binary. So, great :)
I wanna try again with make instead of ninja, but I don't have time now: I'll do it later.

Anyway, the compiled binary has the same segmentation fault problem I encountered with the AppImage, which I hoped to solve by compiling it: open an encrypted file in the editor, then close it with Ctrl+W (doesn't matter if you decrypt it or do other things); instead of closing the tab, the application crashes. I think this problem appeared with 2.1.8.
In the next few days I'll need to update Qt from 6.8.3 to 6.9.1: I'll try recompiling after that and let you know if that fixes the problem, otherwise I'll open a dedicated issue report.

[saturneric]

Thank you for your report! This is indeed a bug in the tab closing logic and I was able to quickly identify and fix the issue. The problem was caused by accessing already deleted objects after closing a tab. I have now simplified and corrected the logic.

Refer: 5ca4a54

The fix will be available in the next Nightly Build. Please try it out once it’s ready and let me know if you still encounter any issues.

[mattemod]

Sorry for the delay, I didn't have enough time to try anything until now.

I tried the 2025-06-29 nightly build:

• I can confirm that the Ctrl+W issue is now fixed, thanks :)
• I was able to build it with ninja on Qt 6.9.1 (the new stable version on Gentoo).
• I was not able to build it with make: there was some separator issue in third_party/CMakeFiles/EP_GpgError.dir/build.make at a line that only contained an indented double-quote. I tried to simply remove the line but it didn't work (different error) and I don't have time to investigate now: maybe another day.

As soon as I can, I'll create an ebuild for Gentoo for the 2.1.9 release, submit it (in this bug report I created ~1.5 years ago https://bugs.gentoo.org/923961) and let you know how it goes.

Thanks for now!

[saturneric]

Sorry for the delay, I didn't have enough time to try anything until now.

I tried the 2025-06-29 nightly build:

* I can confirm that the `Ctrl+W` issue is now fixed, thanks :)

* I was able to build it with `ninja` on Qt 6.9.1 (the new stable version on Gentoo).

* I was **not** able to build it with `make`: there was some separator issue in `third_party/CMakeFiles/EP_GpgError.dir/build.make` at a line that only contained an indented double-quote. I tried to simply remove the line but it didn't work (different error) and I don't have time to investigate now: maybe another day.

As soon as I can, I'll create an ebuild for Gentoo for the 2.1.9 release, submit it (in this bug report I created ~1.5 years ago https://bugs.gentoo.org/923961) and let you know how it goes.

Thanks for now!

I’d be very happy to help with this if possible!

At the moment, I still recommend using Ninja for building, as I’ve never actually tested with make, and Ninja is also faster in practice. If Gentoo could support gpgme-2.0 soon (just like Arch already does), that would be great.

You can also refer to the AUR build recipe here: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=gpgfrontend

Alternatively, this workflow config (see line 287):

GpgFrontend/.github/workflows/testing-nightly.yml

Lines 287 to 295 in 7172499

	- name: Build GpgFrontend (Linux)
	run: |
	export LD_LIBRARY_PATH=/usr/local/lib:/usr/local/lib64:$LD_LIBRARY_PATH
	cmake -B ${{github.workspace}}/build -G Ninja \
	-DCMAKE_BUILD_TYPE=${{env.BUILD_TYPE}} \
	-DGPGFRONTEND_BUILD_APP_IMAGE=ON \
	-DGPGFRONTEND_LINK_GPGME_INTO_CORE=ON
	cmake --build ${{github.workspace}}/build --config {{$env.BUILD_TYPE}} -- -v
	if: runner.os == 'Linux'

These might provide some useful information for building on Gentoo as well.

Lastly, I want to point out that setting GPGFRONTEND_BUILD_MODULES=OFF will disable building some modules, which means features like email support and update checking won’t be available. If you have any further questions or encounter any issues, please feel free to ask.