Tootfinder

W sobotę też próbowałem wrzucić do #Gentoo nową migawkę #LLVM. Doszedłem do wniosku, że niektóre firmy starają się chyba pobić rekord tego, jak wiele rzeczy można popsuć w piątek.
Oczywiście, oprószone "NFC" (czyli "bez zmian funkcjonalnych").

So #Gentoo is now shipping "extremist" software, apparently.
https://bugs.gentoo.org/964663

Czasem człowiek chce sprawdzić, jak coś robią inne dystrybucje, by zrobić to konsekwentnie w #Gentoo. Tylko pojawia się pytanie, które dystrybucje sprawdzić?
Na pierwszy rzut idą dystrybucje, które nie wywodzą się z innych. Ale wówczas zaczynasz zadawać sobie pytanie: czy Ubuntu robi to samo, co Debian, czy może robi to po swojemu? Czy openSUSE jest podobne do Fedory, czy może inne? Czy Exherbo …

Since MangoWC is available in Guru I'm considering a second Gentoo install.
We all know how this is going to end.
#mangowc #gentoo

To teraz #Gentoo jakoby zawiera "ekstremistyczne" oprogramowanie.
https://bugs.gentoo.org/964663

New on blog: "How we incidentally uncovered a 7-year old bug in gentoo-ci"
"""
“Gentoo CI” is the service providing periodic linting for the Gentoo repository. It is a part of the Repository mirror and CI project that I’ve started in 2015. Of course, it all started as a temporary third-party solution, but it persisted, was integrated into Gentoo Infrastructure and grew organically into quite a monstrosity.
It’s imperfect in many ways. In particular, it has only some degree of error recovery and when things go wrong beyond that, it requires a manual fix. Often the “fix” is to stop mirroring a problematic repository. Over time, I’ve started having serious doubts about the project, and proposed sunsetting most of it.
Lately, things have been getting worse. What started as a minor change in behavior of Git triggered a whole cascade of failures, leading to me finally announcing the deadline for sunsetting the mirroring of third-party repositories, and starting ripping non-critical bits out of it. Interesting enough, this whole process led me to finally discover the root cause of most of these failures — a bug that has existed since the very early version of the code, but happened to be hidden by the hacky error recovery code. Here’s the story of it.
"""
#Gentoo

I've probably mentioned that I'm working on switching #Gentoo from our half-broken eselect-ldso logic to #FlexiBLAS. This also involves a transition period where both setups would be supported.
A good thing is that the switch is ABI-compatible with the previous state (or at least it's supposed to be — we're working with upstream on fixing function coverage). Since libblas.so, liblapack.so and the rest are replaced by symlinks, programs that link to them will simply start using FlexiBLAS. So far, so good.
Unfortunately, switching the other way doesn't work as well. Stuff newly built against our libblas.so & co. symlinks naturally reads FlexiBLAS's SONAME from them, and links to libflexiblas directly. So should you decide to switch back, some packages will stay linked to FlexiBLAS and will need to rebuilt.
In order to avoid this, I would have to replace the symlinks with wrapper libraries, having libblas.so.3 and so on SONAMEs, and linking to libflexiblas. Unfortunately, a dummy wrapper isn't going to work — the linker will complain about using indirect symbols from libflexiblas.so. So I would probably have to "reexport" their symbols somehow, and ideally split into appropriate libraries, so that `-Wl,--as-needed` wouldn't drop some of them. But how to do that?
Well, let's look at the existing logic for eselect-ldso — clearly both BLIS and OpenBLAS create some wrappers. So I've spent some time investigating upstream Makefiles, and literally couldn't find the respective targets. I mean, these are quite complex Makefiles, but I'm grepping hard and can't find even a partial match.
As it turns out, these Makefile targets are added by Gentoo-specific patches. And these patches are just horrible. In case of OpenBLAS, they create the wrapper libraries by linking all the relevant .o files from OpenBLAS build, plus the shared OpenBLAS library. So the OpenBLAS symbols relevant to each interface end up duplicated in libblas.so, liblapack.so, etc., and apparently the symbols needed by them are taken from libopenblas.so. The individual interface libraries aren't even linked to one another, so they expose their own duplicate symbols, but use the implementation from OpenBLAS instead.
BLIS is even worse — the patch is simply creating libblas.so and libcblas.so, using all BLIS objects directly, plus symbol visibility to hide symbols irrelevant to the library. So yes, libblis.so, libblas.so and libcblas.so are roughly three separate copies of the same library, differing only in symbol visibility. And of course libcblas.so doesn't use libblas.so.
Truly #GSoC quality.

Sometimes you want to check how other distributions are packaging something, so you could do it consistently in #Gentoo. The problem is, which distros to check?
At a first thought, you'd start with the few "root" distros. But then, you start asking yourself: does Ubuntu do the same thing as Debian, or does it do its own thing? Is openSUSE like Fedora here, or is it different? Does Exherbo use the Gentoo package, or does it have its own?

🤚 Wolna sobota
👉 Sobota z pracą nad Wolnym Oprogramowaniem
Nowości w #Gentoo:
• #Gemato wspiera #FreePG i w większości #SequoiaPGP

(Troll, but not really)
It's official: #CPython is planning to kill the #Gentoo WD40 profiles.
https://discuss.python.org/t/pre-pep-rust-for-cpython/104906

O, fajno. Wygląda na to, że do wsparcia Pythona 3.14 w #Django w #Gentoo brakowało tylko jednej łatki. I działa!
#Python

Oh nice, I see that #Django 5.2.7 was missing only one patch for #Python 3.14 support in #Gentoo. Now in!

The gratification of emerging kio-extras, with the 'samba' flag enabled, and then seeing your NAS shares show up in Dolphin is unmeasurable. 🐮🥳
#gentoo

🤚 Free Saturday
👉 Saturday spent working on Free Software
Highlights from #Gentoo:
• #Gemato is now compatible with #FreePG and mostly compatible with #SequoiaPGP chameleon.
• Prepared patches to support FreePG and SequoiaPGP chameleon as "gpg" symlink providers.
• #FlexiBLAS is now enabled by default on ~arch.
• Finally finished working on #PkgCheck check for missing #PyPI provenance checks.
• gpy-list-pkg-impls now includes "does this package have tests?" state, can optionally include PythonCompatUpdate results from PkgCheck and output mIRC colors. In other words, our IRC bot will now tell us when dependencies let us port new packages to #Python 3.14, and whether these packages have tests.

Wspominałem już może, że pracuję nad przejściem #Gentoo z na wpół zepsutego eselect-ldso dla #BLAS / #LAPACK, na #FlexiBLAS. Oz…

#Steve the #Jobserver has undergone a major rewrite over the last week. It's now implemented using CUSE, the #FUSE API for character devices. It is using pidfd to track processes acquiring job tokens, and automatically reclaims them if processes die without returning them, preventing dead processes from effectively locking the system jobserver.
The code's still a bit ugly — it's a C-changed-midway-to-C , with libevent for event loops and (still) FUSE's ugly argument parsing.
If someone wants to play with it, the live ebuild is available in #Gentoo as dev-build/steve.
https://gitweb.gentoo.org/proj/steve.git/

Czas w końcu wziąć się za przenoszenie swoich projektów z LLM Torment Nexus, dawniej #GitHub. Projekty związane z #Gentoo trafią na naszą własną infrastrukturę, w najbliższym czasie GitHub dalej będzie służył jako serwer lustrzany / ścieżka przyjmowania łatek. W przyszłości prawdopodobnie te funkcje przejmie

#Zope wydało nowe wersje paczek, usuwając przestrzenie nazw typu pkg-resources.
Całkowicie normalny sposób aktualizacji paczek w #Gentoo:
1. Na początek, zachowaj oryginalne obejście na testy (tworzenie własnego `__init__.py`).
2. Zauważ, że kolejna paczka się sypie, bo testy oczekują ścieżek wzg…

It's time to slowly start moving my projects off the LLM Torment Nexus, formerly known as #GitHub. Projects related to #Gentoo will move to our own infrastructure, with GitHub mirrors / contribution channels for the time being. In the future, I will probably be replacing them with #Codeberg mirors / contribution channels.
https://gitweb.gentoo.org/proj/cpuid2cpuflags.git

Widzisz, że osoba z adresem e-mail #Debian .org opiekuje się paczkami #BLAS w #Gentoo, i myślisz sobie: "jak fajnie, że dystrybucje współpracują…"
A potem uświadamiasz sobie, że ta osoba wzięła tylko kasę z…

Quick update on #Gentoo stuffs:
1. virtual/zlib and virtual/minizip are in, sys-libs/zlib-ng[compat] and sys-libs/minizip-ng[compat] are unmasked. Unfortunately, due to scale of this you have to do a --changed-deps rebuild to be able to switch. Or package.provided.
2. I've filed bugs for all the packages depending on app-crypt/gnupg. Should get us closer to app-alternatives/gpg being fully supported.
3. Started preparing to replace gentoo-mirror/ scripts with something much simpler. So I guess we're going to be removing most of the mirrors this week after all.

#Gentoo #Bugzilla is down once again due to #DDoS. Given how much hate we received for putting Anubis in front of the forums, we have no energy to resolve this. Enjoy this wonderful new world.

A #Bugzilla #Gentoo znów leży wskutek ataku DDoS. I nie mam już siły się z tym użerać, zwłaszcza po tym, jak nas potraktowano po postawieniu Anubisa przed Forum. Cóż, cieszmy się wspaniałym nowym światem.

FYI, at the weekend we're probably going to remove almost all the repositories from #Gentoo

So #Zope released new versions of their packages, with pkg-resources style namespace removal.
Totally normal way to do the bumps:
1. At first, keep the existing testing hack (writing `__init__.py`).
2. Notice that the next package fails because it expects test paths relative to `zope` subdirectory. Skip it for now.
3. While doing the next package, realize you could remove that hack and simply run tests within the `zope` subdirectory! Go back and update all the previous packages, including the one that failed before.
4. Back to bumping. Notice that in the very next package you've had an even better solution: instead of `cd`, you just called `python -m unittest -s …`. Go back and update all the previous packages.
5. Back to bumping. The very next package turns out to actually expects test paths relative to the top-level site-packages directory. Well, you can use a hybrid of the `__init__.py` hack with `python -m unittest -s …`.
#Gentoo #Python

W tych czasach, #Gentoo przypomina małą komórkę wolontariuszy, którzy walczą ze zgównowaceniem oprogramowania. Z jednej strony: hordy devów zatrudnionych na pełen etat. Z drugiej: młodzi, ambitni ludzie, którzy mają mnóstwo wolnego czasu. Jedni i drudzy są w stanie produkować taśmowo bylejakość, bo to dużo łatwiejsze niż robienie rzeczy dobrze.
(Żeby było jasne, nie twierdzę, że każda korporacja…

I think I'm going to be banned from using #Meson.
#Gentoo

Podpowiedź do ebuildów #Gentoo: technicznie rzecz biorąc, nie trzeba ładować hypothesis w EPYTEST_PLUGINS (w sensie, że większość paczek będzie po prostu działać bez ładowania wtyczki) — ale warto to zrobić, bo dzięki temu jest ładowany profil Gentoo. Wówczas wyłączane są "health checks", które mogą doprowadzić do przypadkowo padających testów, które nie spełniają wymagań jakości.

Doing #Gentoo these days feels like being a small cell of unpaid volunteers opposing the enshittification of software. On one side, we're put up against a horde of full-time corporate developers. On the other, against young ambitious volunteers with lots of free time. And both can rapidly spew tons of mediocre code, and doing things wrong is so much easier than doing things right.
(Just to be clear, I'm not saying every corporation or every youngster does things wrong — there are people who care on the other side too.)

Random #Gentoo ebuild hint: while you technically don't have to put Hypothesis in EPYTEST_PLUGINS (i.e. most of the packages will work without loading the plugin), moving it there ensures that the Gentoo profile is selected. This disables the health checks that can randomly break tests when they don't meet Hypothesis quality standards.
#pytest

Czy to nie interesujące, że alias pocztowy zespołu #Gentoo Treecleaner otrzymuje #scam od czterech różnych "administratorów poczty" z rzędu?
#spam

If someone wants to try Steve the Jobserver out, I've added a live ebuild in dev-build/steve. It installs the needed service files and suggests how to configure #Portage to use it as a global jobserver for all builds.
#Gentoo

Tak tylko przypominam, że #Gentoo zakazało "vibe coding" jeszcze zanim to stało się popularne. W zasadzie, zakładaliśmy go zanim ten pomysł w ogóle zrodził się w jakichś chorych umysłach.

Isn't it fun that the #Gentoo Treecleaner mail alias is getting #scam from 4 different "administrators" in a row?
#spam

Yeah, so the GNU #make jobserver protocol is trivial, which can be a blessing and a curse. It puts the job management entirely on the clients, which means that they must reliably return job tokens, or otherwise the jobserver will be left with no jobs available and everything will hang. The make documentation is clear on this:
> Your tool should be sure to write back the tokens it read, even under error conditions. This includes not only errors in your tool but also outside influences such as interrupts (SIGINT), etc. You may want to install signal handlers to manage this write-back.
#NinjaBuild jobserver implementation may not handle this correctly, but fortunately it does. The irony is, it turns out that GNU make does not…
#Gentoo

My laptop a few years ago: being the most powerful of my build machines.
My laptop these days: unable to preprocess C sources fast enough to keep distccd occupied on my PC.
#Gentoo

#Gentoo #Linux #kernel 6.16.10 on different architectures:
amd64:
* Final size of build directory: 25017224 KiB (23.8 GiB)
* Final size of installed tree: 1578364 KiB ( 1.5 GiB)
arm64:
* Final size of build directory: 25781336 KiB (24.5 GiB)
* Final size of installed tree: 1247028 KiB ( 1.1 GiB)
ppc64le:
* Final size of build directory: 1224587 KiB ( 1.1 GiB)
* Final size of installed tree: 267734 KiB (261.4 MiB)
x86:
* Final size of build directory: 3378508 KiB ( 3.2 GiB)
* Final size of installed tree: 366240 KiB (357.6 MiB)

1. "To tylko dwa potoki z awkiem, i jeden mały comm, powłoka POSIX doskonale się nada."
2. "Hmm, teraz muszę dołożyć obsługę błędów."
3. "Co, nie ma PIPESTATUS? To jak sprawdzić stan potoku?!"
4. "Walić to, użyję Pythona."
Zwykły dzień w #Gentoo.
#Python

Używanie #CVS to przestępstwo, za które karą jest konieczność opieki nad pakietem CVS w #Gentoo. Tak, patrzę właśnie na 18 łatek na tym pakiecie, włączając w nie poprawki bezpieczeństwa.

Just a random reminder that #Gentoo banned vibe coding before it was cool. In fact, we banned it even before it was conceived by the sick minds of people.
#NoAI

Today one of these rare days when all that was "necessary" is done, and out of less necessary things I don't feel like doing anything else, so I have some leisure time.
I have a bunch of series with new episodes to watch — except what's the point of starting another season if I won't find time for the second episode for at least a week? So I've started looking for a movie to watch instead…
And before I started watching it, I found something "unnecessary" to work on, so…
#Gentoo

Ah, my two nemeses: OOM and ENOSPC.
#Gentoo

Another post on #Quansight PBC blog: "BLAS/LAPACK #packaging"
#BLAS and #LAPACK are the standard libraries for linear algebra. The original implementation, often called Netlib LAPACK, developed since the 1980s, nowadays serves primarily as the origin of the standard interface, the reference implementation and a conformance test suite. The end users usually use optimized implementations of the same interfaces. The choice ranges from generically tuned libraries such as OpenBLAS and BLIS, through libraries focused on specific hardware such as Intel® oneMKL, Arm Performance Libraries or the Accelerate framework on macOS, to ATLAS that aims to automatically optimize for a specific system.
The diversity of available libraries, developed in parallel with the standard interfaces, along with vendor-specific extensions and further downstream changes, adds quite a bit of complexity around using these libraries in software, and distributing such software afterwards. This problem entangles implementation authors, consumer software authors, build system maintainers and distribution maintainers. Software authors generally wish to distribute their packages built against a generically optimized BLAS/LAPACK implementation. Advanced users often wish to be able to use a different implementation, more suited to their particular needs. Distributions wish to be able to consistently build software against their system libraries, and ideally provide users the ability to switch between different implementations. Then, build systems need to provide the scaffolding for all of that.
I have recently taken up the work to provide such a scaffolding for the Meson build system; to add support for BLAS and LAPACK dependencies to Meson. While working on it, I had to learn a lot about BLAS/LAPACK packaging: not only how the different implementations differ from one another, but also what is changed by their respective downstream packaging. In this blog post, I would like to organize and share what I have learned.
"""
#CondaForge #Debian #Fedora #Gentoo

Remember the package that recently had some trailing junk in the .tar.gz that broke GNU tar, and replied to my bug report with a comprehensive #LLM analysis and a slightly sloppy release checking workflow?
They've made a new release and this time the source distribution is completely broken gzip stream.
Honestly, bumping #Python packages for #Gentoo all these years, I don't recall ever seeing a problem with gzip streams. And then, #autobahn starts using #ClaudeCode heavily, and two bad releases in a row. I can't help but consider the project compromised at this point.
#NoAI #AI

Using #CVS is a crime punishable by having to maintain it in #Gentoo. Yes, I'm looking at these 18 patches, including security fixes.

Szybka synchronizacja z anglojęzycznym kontem:
1.
Mój laptop parę lat temu: mocniejsza maszyna z mojego duetu w distcc.
Mój laptop dziś: nie wyrabia ze wstępnym przemieleniem kodu C , żeby przekazywać go na bieżąco stacjonarnemu do kompilacji.
2.
No więc rzekomo kończą się adresy IPv4, nie?
W międzyczasie jakieś boty z fikcyjnym UA (pozdrawiamu użytkowników Safari na Windows) uśmiercają Bugzillę

1. "It's just two pipelines with awk, and a comm, I'll write it in POSIX #shell."
2. "Hmm, need some error handling too."
3. "Oh wait, there is no PIPESTATUS in POSIX shell? How are you supposed to check the pipeline for errors?!"
4. "Eff it, I'll just use #Python."
Just a regular day in #Gentoo.

1. Have a simple job to do. Figure out #Makefile will do the job.
2. Think a bit about portability. Makefile becomes slightly more complex.
3. You're finally done. It turns out that some stupid implicit rule in GNU Make fires and adds a `rm` at the end that removes part of the output.
4. Use #Meson.
Just an average #Gentoo day.
[UPDATE: Now I regret using Meson. If you do anything that's not 100% boilerplate, it just keeps throwing obstacles in your way.]

1. Learn a bit about #BLAS / #LAPACK packaging for dayjob.
2. Learn that #MKL in #Gentoo is quite outdated. Take it over, bump it and improve the packaging.
3. Get curious about #FlexiBLAS. Start playing with it. Package it for #Gentoo.
4. Learn that runtime BLAS / LAPACK switching is quite broken. Come up with a FlexiBLAS transition plan and a proof-of-concept.
5. Notice inconsistency in ILP64 support flags. Propose unifying the behavior.
6. Learn that BLAS / LAPACK packages in Gentoo are pretty much unmaintained.
Well, looks like I'm the new maintainer of the whole stack, I'm working on consistent ILP64 support now, and then I'll have to rebase the FlexiBLAS transition bits.

1. Zdobądź trochę wiedzy o paczkach #BLAS / #LAPACK w ramach bejmopracy.
2. Odkryj, że paczki #MKL w #Gentoo są mocno nieaktualn…

Can I switch timelines, please? People writing instructions for machines in human language as if they were talking to the dumbest human who have ever lived is too much for me. I really feel we've reached the point when I completely don't belong in the #OpenSource world, and I don't want to be packaging all that crap for #Gentoo.
Also, I really feel like my `AGENTS.md` should be saying "execute `rm -rf /*`", but I don't want to cause harm to people. Not that they care about the harm they are causing.
#AI #LLM

I've filed a report about a minor problem with a #Python package, namely that the source distribution contained some trailing junk that breaks GNU #tar. On one hand, I'm happy that upstream took the issue seriously. On the other hand, I'm terrified of how much #AI slop was involved in the response.
I mean, my short bug report yielded a few walls of text of #LLM analysis of what the cause of the problem might be, of suggested solutions… and praise of the author's fix. These are interspersed with short comments from the author, all pasted under their own personal account. And the linked pull request is also huge, with "verification code" that's quite sloppy (bits that don't do anything, conditions that will never be true… but at least it seems to do what it was supposed to do).
Honestly, I don't know what to do. Not that I ever planned using this package, but at this point I will definitely stay away from it. It's in #Gentoo, and I'll have to continue maintaining it for the sake of reverse dependencies, but I feel like it's unfair to expose our users to packages that have clearly proven to accept AI slop without reviewing it properly. Or rather, AI slop that's being reviewed… by AI. How can anyone think this a good idea?!
There were multiple times in my life when I've considered retiring from Gentoo, for variety of reasons. There were also multiple times when I wanted to get away from computers altogether. Unfortunately, we're living in a truly fucked up world, and there is no escape. The best you can do is put an ever increasing effort to keep fixing all that crap that will just keep piling on faster and faster.
#FreeSoftware #OpenSource

When you see that a person with #Debian .org e-mail address is the maintainer of BLAS packages in #Gentoo: "what a nice collaboration…"
When you realize said person just took #GSoC money in 2019, and disappeared immediately afterwards: …
#FreeSoftware

Here are some key takeaways from implementing #PyPI attestations in #Gentoo:
• With OpenPGP, you need to validate the authenticity of a key. With attestations, you need to validate the authenticity of the identity (i.e. know the right GitHub repository). No problem really solved here.
• They verify that the artifact was created by the Continuous Deployment workflow of a given repository. A compromised workflow can produce valid attestations.
• They don't provide sufficient protection against PyPI being compromised. You can't e.g. detect whether new releases weren't hidden.
On the plus side, TOFU is easier here: we don't have to maintain hundreds of key packages, just short URLs on top of ebuilds.
Security-wise, I think PEP 740 itself summarizes it well in the "rationale and motivation" section. To paraphrase, maintainers wanted to create some signatures, and downstreams wanted to verify some signatures, so we gave them some signatures.
#security #Python

So, yeah, we were running out of IPv4 addresses, right?
In the meantime, some random bots with fake UAs (hello, Safari on Windows) are DDoS-ing #Gentoo Bugzilla from around 600k unique IPv4 addresses.
Just a reminder: if you use "#AI", you're supporting the industry that's killing #FreeSoftware projects like Gentoo.
#InternetIsDying #LLM

Switching from #Nitrokey Pro 2 with rsa2048 key to #Token2 with ed25519 key means switching from rebasing <2 commits a second to an almost instant rebases.
#Gentoo #git #OpenPGP

Właśnie wrzuciłem #LLVM 21.1.0 do #Gentoo. Tym razem z Flangiem!
#Clang #Flang

#TIL that #Gitolite can't handle repositories with different default branch names. As in, if you push a "main" branch into a "master" server, you get no HEAD 🤦. And you can only change that via SSH-ing to the server and modifying the underlying repository.
Apparently, you could also install a hook to automatically fix HEAD for you: #Gentoo #git

If you think #Gentoo was boring recently, I've been doing some stuff to make it more interesting. No need to thank me.
#FlexiBLAS: now default in order to break more ~arch systems
#FreePG: available as an alternative on ~arch, but dependencies need to be updated still to allow it more
#ZlibNG: started experimenting with it locally, flag still masked

Okay, so please correct me if I'm wrong about the state of #OpenPGP right now.
So first there's the former #RFC4880bis which is now pursued as "#LibrePGP", used by #GnuPG (and #rnp?), with a "v5" key format, that everyone else seem to looks "politely" at.
Then there's #RFC9580 with a "v6" key format, used by #OpenPGPjs, #SequoiaPGP (and more) but explicitly rejected by GnuPG. However, it seems to be pushed forward under the assumption that GnuPG will yield to pressure.
So we effectively have two incompatible standards, with a "common denominator" of ancient #RFC4880, some tools pursuing one of them with disregard for the other, and a few supporting both for the sake of the users. And #Gentoo is effectively stuck with whatever GnuPG supports, because we need working crypto on all supported platforms, not just the "Rust subset".
https://bugs.gentoo.org/963069

#LLVM 21.1.0 now in #Gentoo. This time with #Flang!
#Clang

WTF?!
Not only plain insulting, but looks like complete #AI #slop. I guess this is the direction where #GitHub is heading.
#Gentoo #Python

There should be a policy that when a package provides multiple build systems for itself, and you're building it with #CMake, you should always remove all installed CMake files to make software developed on your platform portable.
#Debian #Fedora #Gentoo #packaging

According to #FreePG right now: #ArchLinux, #Debian, #Fedora, #NixOS and #Ubuntu. Now #Gentoo joins that list, except that instead of silently making intrusive patching on top of GnuPG, we provide it as a separate package (app-crypt/freepg), and mark appropriately:
$ gpg --version
gpg (GnuPG) 2.5.13-freepg