I note that @DemiMarie offered a patch for this over a year ago. It doesn't appear to have had any review. If it's good, maybe apply it? If it's problematic, can we identify the problem?

Thanks, I confirm that this new commit is fixing the issue.

In general, asking an application change is not good. Migrating to pkg-config should be an option.
However, it's usually recommended to use libgpg-error when an application is used with libgcrypt/libksba/libassuan.

by all means, please proofread it! thanks for the attention to detail. what was the grammar glitch?

I still spotted a grammar glitch in corrections. Thus if we apply this we need to proofread it.

Thank you for testing. Now, I can see the exact reason by your npth log.
Pushed another change: rPTH75c68399ef3b: Fix previous commit.

Build is still failing even with this commit, here is an extract of npth log:

Just to clarify: I personally think it would be perfectly fine to say that AM_PATH_* is only supported when AM_PATH_GPG_ERROR is also used. Adding an invocation AM_PATH_GPG_ERROR is not a great hassle and alternatively pkg-config/pkgconf exists and works perfectly fine (and is a lot faster).

I noticed this recently too on some boxes. Thanks for the good decription. This support for pkg-config style .pc files for our config scripts seems to be a never ending story. The alternative name for libgpg-error-config does not make it easier.

Thanks for report. I've applied this change to master.

The official GPG binary from "c:\Program Files (x86)\GnuPG\bin\gpg.exe" does not exhibit this problem. I will report it to the msys2 folks.

Yes, it is the msys2 build of gpg, installed using the standard msys2 methods. The pwd in my example was from msys2 zsh.
I reproduced the error running under msys2 zsh and in Powershell.
If I understand your response correctly, you are saying this will not be fixed in gnupg itself? I can report it to the cygwin/msys2 folks of course, if you think that is best. But I still suspect the root cause is in gnupg, probably in homedir.c or the code that makes an absolute path from a relative one.
I will retest with the official gpg4win and let you know the results.

pwd is not a standard Windows command. It is availabe in powershell but there I get

I think so. We did not submit a modules for recertification with these changes, but we do not plan this in close future so you can consider it completed.

Can we close this?

Backported for VSD 3.3 even though the issues only occurred in the Qt 6 build.

Please test with: rPTH01f03a91c9bd: Return a run-time error if npth_rwlock_timedrdlock is not supported.

Could you show us the build log of nPth, please?

Meanwhile version 1.32.2 builds. Greatest change is Python 3.12 instead of 3.11…

Seems it was a kernel / USB bug

Sorry, I meant they do *not* arrive at the web interface, they are not visible to me.