#Arch: #GPGME-Fehler

Wer eine #Arch-basierte #Distribution verwendet, sollte mit Problemen rechnen und diese beheben können. Entweder mit eigenem Wissen oder mithilfe der #Community.

Wer eine #Rolling #Distribution verwendet, muss früher oder später mit Problemen rechnen. Das gilt auch für das kuratiert-rollende #Manjaro. Es können jahrelang überhaupt keine Schwierigkeiten auftreten, oder es kommt auf einmal knüppeldick.

https://gnulinux.ch/arch-gpgme-fehler

Arch: GPGME-Fehler

Wer eine Arch-basierte Distribution verwendet, sollte mit Problemen rechnen und diese beheben können. Entweder mit eigenem Wissen oder mithilfe der Community.

GNU/Linux.ch

Arch: GPGME-Fehler

Wer eine Arch-basierte Distribution verwendet, sollte mit Problemen rechnen und diese beheben können. Entweder mit eigenem Wissen oder mithilfe der Community.

#GPGME #arch #Manjaro #Update #Fehler #Linux

https://gnulinux.ch/arch-gpgme-fehler

Arch: GPGME-Fehler

Wer eine Arch-basierte Distribution verwendet, sollte mit Problemen rechnen und diese beheben können. Entweder mit eigenem Wissen oder mithilfe der Community.

GNU/Linux.ch
#Bootstrap fun: #libassuan upgraded its symbols separately from its #soname in a patch-level release (with several weeks in between!)
On #ArchLinux we had upgraded to the weird version that has a soname change but no symbol change.
Since #pacman requires the library transitively via #gpgme, there now is no clean way to upgrade this without patching all consumers in some intermediate step. 🗑️ 🔥
(The staging build environment would otherwise have a broken pacman and thus not be functional).
Script to bump the KF5 #KDE frameworks reviewed and checked, KF5.116.0 up and running, meanwhile did a rebuilt for #Qt5 to use more uptodate version for #LLVM and #ICU, PR/MR's for Qt are up for review alongside with one for #gpgme to add support for #Qt6 (needed for the KF6 frameworks).
Is it important for (#GNU) projects how they are built so that they can be distributed as packages by Linux/BSD distributions? All qt5 -qt6 flavors are crap. #signon #libaccounts-qt and many more ... #gpgme is the winner 💩
I had a little trouble getting #PGP working with #Enigmail -plugin, because for some reason the #Debian #gpgme -package does not include gpgme-json. I tried rebuilding the package, but encountered errors. I ended up just copying the script into /usr/local/bin. Then I forgot to set the permissions correctly. Once I finally realized and corrected that, Enigmail started working.

@dalias @nemobis @davidgerard

That last one is very disappointing for me.

I've been using #Python since 1999 and in 2018, while I was busy working on the official Python bindings of the #GnuPG #GPGME #C #API, the #PSF decided that I and everyone like me are persona non grata.

So be it.

21/24

After thinking about it a bunch, I have decided that I'll refactor my cryptographic deadhand to use python-gnupg until the sequoia-sop python bindings are released.

The official #GPGME bindings are just too damn broken to be of any real use – and I think that says *a lot*.

Honestly, I'm not at all sure how people can release something like that as "production grade" (for security-critical tooling, no less) and not feel deeply ashamed.

Further #GPGME python binding adventures.

gpg.Context.key_import, unlike what the docs claim, doesn't raise any Exception if you pass in the wrong kind of data, but rather just returns the string "ERROR" and neither return values nor what type of data the function expects are documented.

I continue to be amazed by how #GnuPG manages to be broken for pretty much every. single. thing.

I've been trying for an hour to get the python bindings of #gpgme to generate a key and it just keeps failing with the most generic error message imaginable: gpgme_op_createkey: GPGME: General error

Literally the only information I get out of that is that the key creation failed – no duh… 🙄