gpgme: 1.23.2 -> 1.24.0

[dotlambda]

fixes #354166
cc @lucc

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[SuperSandro2000]

We should merge all of meta to not forget anything, right?

[dotlambda]

I thought that creates problems with meta.position but it must be some other problem.

[dotlambda]

@Atemu @eclairevoyant Can you explain why I get

nix-repl> python3.pkgs.gpgme.meta.position
"nixpkgs/pkgs/development/python-modules/gpgme/default.nix:45"

here despite using meta = gpgme.meta // ...? C.f. #324127 (comment)

[Atemu]

It's because, not despite.

[dotlambda]

But removing gpgme.meta // yields the same meta.position.

[emilazy]

I think meta.position is unconditionally overwritten based on pos (when present), or something.

[lucc]

Just some code nitpicks. Thanks for splitting it into a proper python derivation with the import check.

Do I understand the code correctly, that the python derivation depends on the binary library derivation and also executes the configure script in the sources again but does not build the binary library again?

[dotlambda]

Do I understand the code correctly, that the python derivation depends on the binary library derivation and also executes the configure script in the sources again but does not build the binary library again?

Yes. The configure script at least sets the version, i.e. replaces @version@, while turning setup.py.in into setup.py. I could do that manually instead but I don't think there's a lot of harm in running the script.

[dotlambda]

The question is: Is this acceptable for staging-next? Otherwise it won't land in 24.11.
I tried only applying the second commit but ran into the same problem as #354166, even after adding distutils to build-system.
cc @NixOS/nixos-release-managers

[RossComputerGuy]

The question is: Is this acceptable for staging-next?

I'm not sure, lemme ask the staging folks. I would say yes.

Otherwise it won't land in 24.11.

Yeah, we should fix this before 24.11's release.

[RossComputerGuy]

Well it looks like this won't make it to 24.11, should go back to staging and it can land in there once approved enough.

[dotlambda]

I don't understand why python313.pkgs.gpgme fails to build with

checking for swig... /nix/store/8w5lfkjysan93sv31rmjxbpw1g1iv115-swig-4.2.1/bin/swig
checking for a Python interpreter with version >= 2.7... none
checking for a Python interpreter with version >= 3.6... none
checking for a Python interpreter with version >= 3.8... none
checking for a Python interpreter with version >= 3.9... none
checking for a Python interpreter with version >= 3.10... none
checking for a Python interpreter with version >= 3.11... none
checking for a Python interpreter with version >= 3.12... none
checking for a Python interpreter with version >= all... none
configure: error: 
***
*** Please install the python development packages.
***

@mweinelt Any idea?

[lucc]

@dotlambda I think that is the configure script of gpgme which tries to find a suitable python version and they have hardcoded a list :/

Maybe there is an option to tell configure to just use one specific python executable and not search for it, but I did not find that option at first glance.

[dotlambda]

@lucc Did you even look at this PR's diff? There's a patch that changes said list.

[dotlambda]

Should we merge this anyway and fix Python 3.13 later?

[dotlambda]

@ofborg build gpgme.passthru.tests python313.pkgs.gpgme

[github-actions]

Backport failed for staging-24.11, because it was unable to cherry-pick the commit(s).

Please cherry-pick the changes locally and resolve any conflicts.

git fetch origin staging-24.11
git worktree add -d .worktree/backport-354635-to-staging-24.11 origin/staging-24.11
cd .worktree/backport-354635-to-staging-24.11
git switch --create backport-354635-to-staging-24.11
git cherry-pick -x b3797b6d48b59ca5d8e1c991278d33ad48bde9bd 29c88a0ce64fed33d93d02605c8420ff42d570ee

[FliegendeWurst]

Fix for python313Packages.gpgme: #371188