It's tested by gnupg master (for gnupg26) for a year. Let us move on.

Thank you. Applied by : rM87061c0260bb: gpgme.m4: Set $host correctly always.

Ditto for ksba and assuan.

The gcrypt change works for me. Thanks!

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

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.

Oh yeah the idea to implement aliases is more than 20 years old. I guess it is even older. Thanks.

Along with the monitor we should also implement a domain selection feature.

I think we should close this bug or re-purpose it to silence those warnings in common cases.

That could be fixed in src/argparse.c:set_opt_arg by adding and endptr to the strtol calls and check that only white space follows. However, there is some risk of regression with this approach. Maybe just display a warning?

With today's release of npth everything should be set.

Thank you for the fix. Pushed the change modifying the commit log for the ChangeLog entry.

Alright.

Push the change as rE4a9def77488f: estream: Fix call to string filter for estream-printf..

I see your point: allocating STRINGBUF to make sure nul-terminated string.
The code itself doesn't work well in a test case of tests/t-prinntf.c, because it assumes string filter should be called with NULL for string.

Like this:

@@ -1196,10 +1196,25 @@ pr_string (estream_printf_out_t outfnc, void *outfncarg,
    future, when breaking API/ABI is OK, we can change signature of
    gpgrt_string_filter_t to have another argument for precision.  */
   int allow_non_nul_string = (arg->precision >= 0);
+  char *stringbuf = NULL;

We could also pass a nul terminated copy to the filter function in pr_string.

@item handling with @table has been pushed.

I learned about how @item is handled by TeX. By @table command, user specifies how to handle the item line. In the case of GnuPG, it is like:

@table @gnupgtabopt
@item --version
...
@item --help

(Emacs uses @table @samp, while GCC uses @table @gcctabopt.)
And @gnupgtabopt is a macro which is expanded to @code{\body\}

Possible approach for source texinfo files and yat2m would be:

I found a regression for @item --version; It emits \[en]version for roff.

Pushed my fix to support them.

I guess we should add an extended API to set the filter.

I guess we should follow the GNU standards and provide only info files ;-)

Other problems of yat2m transformation:
https://bugs.debian.org/1050886

Not easy do decide whether something is a PIN or a PUK and we will need to check a lot of places. So, not now.

I found a troff reference: https://www.quut.com/berlin/ms/troff.html

Ideally, we should change the source document to use @minus{} for a minus sign, and keep - only when it means a hyphen. But we cannot do that blindly; We need to handle it with care, in a way of case by case (Texinfo manual suggests no use of @minus{} with @code or @example, but it is needed for groff man pages in many cases).... We would need to consider each occurrence of - in our document. That's too much (if it were me to fix).

Pushed the change to:

• libgpg-error
• libassuan master
• libgcrypt master
• ntbtls
• npth
• libksba
• gpgme
• scute

It looks to me like it's marginally more common to *not* use the lib prefix for pkgconfig files:

I pushed the commit: rE64532db11fcd: build: New configure option --with-libtool-modification.

Pushed the change to libgpg-error.

That assumes that libtool won't change substantially as it did several times in the past and broke our cross compiling stuff. But as long as we keep the ltmain.sh in our repo and tarball the patch is okay because it better documents the chnages.

I learned that AC_CONFIG_COMMANDS macro can be used to improve the case of config.status.

How about the change like:

I have built it according to the method described here.
(https://wiki.documentfoundation.org/Development/BuildingOnWindows)

I wonder why you mention Visual Studio and Cygwin? Either it is Cygwin or a native Windows build.

Pushed to GnuPG master. Let us test. For my machine of Debian GNU/Linux, Wine emulation (Windows 32-bit, Windows 64-bit), make check goes all well.
After confirming the implementation, I'd like to put it into gpgrt.

I learned that Unix build environment needs Wine emulation (with winepath) for MinGW host (when uninstalled executable should run correctly).
https://www.gnu.org/software/libtool/manual/html_node/File-name-conversion.html