Last week:

• a bit more around gpgrt-config
• smartcard: UI enhancement for KDF and UIF
• Release Chopstx 1.12 and Gnuk 1.2.11

This week:

• Gnuk 1.2.12 with fix for GD32F103 unique ID bits
• gpg-agent call-scd child process management fix: a race condition : calling assuan_release while it's still in use by another thread
• investigate a race condition in scdaemon using ack button

Last week:

• Another round: build for Debian native (amd64 and arm64), Debian multiarch cross (for i386 on amd64, for armhf on arm64), SuSE native multilib (various), Debian cross for mingw, using new gpgrt-config.
• Fixed small bugs (libassuan, ntbtls, gnupg) by examining build logs (mainly by arm with alignment and i386 with 32-bit object).
• Pushed new gpgme.pc and gpgme.m4 which uses gpgrt-config with gpgme.m4
  • This will be useful after the release of new libgpg-error and libassuan.
  • Before that, it's just another file.
• Gnuk: Struggled with a race condition which has been revealed now by ACK/Confirmation button
  • Figured out a long standing bug
    • Gnuk's sending data should be protected
    • Sending while TX busy causes lower level USB disaster which cannot be recovered in existing code
    • Before ACK button support, there is only key generation which may occur this condition
  • Release and Announcement delayed because of this bug

So far, so good.

I think that it's good to rewrite enum_secret_keys in g10/skclist.c.

The bug is gone by {rG791f165d}.

Here are warnings:

If we can assume C99, we have the type.
I know, it is not guaranteed to be enough size. For particular host (Windows 64-bit), it works.

I'm out of office and I will connect with my phone from a hotel in Tohoku.

To avoid the drawback, we can put the logic of locating possible libdir in gpg-error.m4, instead of putting in the script.

Last week:

• UIF flag handling fix for GnuPG
• gpgrt-config
  • something like gpg-error-config which support pkg-config .pc file
  • very simple one, not intended to support full features
• gpg-error.m4
  • Now, it also detects gpgrt-config so that configure can use it for detecting cflags and ldflags which used to do with *-config.
• *.m4 (libgcrypt, libassuan, libksba, ntbtls, npth)
  • Finally supports all intended cases of cross build
    • GNU standard way with prefix: for example, --prefix=/usr/x86_64-w64-mingw32 --host=x86_64-w64-mingw32
    • Debian and its derivatives, multiarch: for example, --prefix=/usr --libdir='${prefix}/lib/i386-linux-gnu' --host=i686-linux-gnu (on x86_64 machine)
    • Gento/Fefora/Arch/... multilibs

This week:

• I should release Gnuk for FST-01SZ, finally.
• Shall I put *.m4 (libgcrypt, libassuan, libksba, ntbtls, npth) into gnupg/m4 in master?
• consider backporting libgcrypt.m4 and libgcrypt.pc file to 1.8.x.

IIUC, in Gentoo multilib (or other distributions), <triplent>-{gpg-error,libgcrypt,libassuan,npth,libksba,npth}-config script is used.
In forthcoming libgpg-error 1.33, single gpgrt-config is used for all architecture, by having --libdir option at invocation time.

New gpg-error.m4 detects gpgrt-config, too.
And configure supplies --libdir when it invokes gpgrt-config.
For other *.m4 (libassuan, ksba, libgcrypt, ntbtls), it is possible for them to check GPGRT_CONFIG to use gpgrt-config if any.
For npth.m4, it can do that too, with no hard dependency to libgpg-error.

I decided to change gpgrt-config to have --libdir option.
By supplying libdir directly, it's no need anymore to detect the directory by CC variable.
gpg-error.m4 is also updated.

I need more information:

• where is pkg-config path for <host_alias>? How is it determined?
  • 32-bit: /lib or /lib32?
  • 64-bit: /lib or /lib64?
  • something like x32: where???

I consider:

• Single gpgrt-config is better (and simpler)
• new option --for-host=<host_alias>? (--host is already used for query for host)
• update *.m4 for that

libassuan: Done
libksba: Done
npth: Done
ntbtls: Done
libgcrypt: Done