| 19 Dec 2025 |
 @ghpzin:envs.net | Another weird thing is, libkleo is not the only thing that has qgpgme in dependencies.
But all other things seem to build fine (at least ones that are not blocked on other deps broken on staging-next), so are they not using it or just find gpgme in some other way. | 12:14:04 |
| @ghpzin:envs.net | Another weird thing is, libkleo is not the only thing that has qgpgme in dependencies.
But all other things seem to build fine (at least ones that are not blocked on other deps broken on staging-next).
So are they not using it or just find gpgme in some other way. | 12:14:18 |
 K900 | I think the gpgme setup is pretty cursed | 12:19:51 |
| K900 | Anyway feel free to leave it alone and I'll take a look when I'm less migraine | 13:31:44 |
| @ghpzin:envs.net | Thank you.
If nothing else works as mentioned adding gpgme gpgmepp libgpg-error into extraPropagatedBuildInputs seems to at least build libkleo and all other things depending on it. | 13:34:14 |
| K900 | I don't know why it wants all three | 13:34:59 |
| K900 | Maybe gpgme needs to propagate the other two? | 13:35:06 |
| @ghpzin:envs.net | As I understand all these things (including qgpgme) except for libgpg-error were one and the same before that update PR.
So there was never a question of propagating, it was just a bundle with all cmake .pc files and everything together. | 13:37:06 |
| @ghpzin:envs.net | As I understand all these things (including qgpgme) except for libgpg-error were one and the same before that update PR.
So there was never a question of propagating, it was just a bundle with all cmake, .pc files and everything together.
Not sure how person doing that PR decided on how split should work. | 13:37:44 |
