Actually we are using gpgme already for 64 bit Windows; but statically linked.

In T7036#186290, @ebo wrote:

Tested with VS-Desktop-3.2.93.391-Beta:

Tested with VS-Desktop-3.2.93.391-Beta:

Hopefully fixed by disabling the DeviceInfoWatcher on Windows again.

Ah, I see what's up with the man page. It's documenting the Glibc getdents64() wrapper interface, so that's why it uses the Glibc types. But gpgme isn't using that wrapper, it's doing the syscall directly, so it should use the types the kernel uses, which as you've noticed are just generic unsigned and signed 64-bit integers, matching what my patch does.

/include/linux/dirent.h defines

struct linux_dirent64 {
	u64		d_ino;
	s64		d_off;
	unsigned short	d_reclen;
	unsigned char	d_type;
	char		d_name[];
};

In D600#6448, @ikloecker wrote:

$ man getdents64

getdents64()
    The  original  Linux getdents() system call did not handle large filesystems and large file offsets.  Consequently, Linux 2.4
    added getdents64(), with wider types for the d_ino and d_off fields.  In addition, getdents64() supports an  explicit  d_type
    field.

    The  getdents64()  system call is like getdents(), except that its second argument is a pointer to a buffer containing struc‐
    tures of the following type:

        struct linux_dirent64 {
            ino64_t        d_ino;    /* 64-bit inode number */
            off64_t        d_off;    /* 64-bit offset to next structure */
            unsigned short d_reclen; /* Size of this dirent */
            unsigned char  d_type;   /* File type */
            char           d_name[]; /* Filename (null-terminated) */
        };

$ man getdents64

getdents64()
    The  original  Linux getdents() system call did not handle large filesystems and large file offsets.  Consequently, Linux 2.4
    added getdents64(), with wider types for the d_ino and d_off fields.  In addition, getdents64() supports an  explicit  d_type
    field.

In D600#6445, @gniibe wrote:

If it is intentional change by musl (requiring some changes by an application), we can use __ino64_t_defined and __off64_t_defined macro to see if those types are defined or not.

Fixed in gpgme 1.21.0.

If it is intentional change by musl (requiring some changes by an application), we can use __ino64_t_defined and __off64_t_defined macro to see if those types are defined or not.

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

off64_t mat not the same as int64_t

Breaks them how?

In D600#6438, @werner wrote:

This breaks existing 32 bit systems with the 64 bit types.

This breaks existing 32 bit systems with the 64 bit types. Thus a test for off64_t is required which redefines it to int64_t if it does not exist.

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

It seems my eMails to gnupg-devel@gnupg.org do reach the list …

Of course, it should be possible to toggle "disabled" in Kleopatra.
A (context) menu entry "disable certificate" (or "enable certificate") should be sufficient.

Oops. I closed the task accidentally.

Fixed (for GnuPG 2.4). I hope 2.2 prints the same status messages.

The General Error happens also when the PIN is blocked and no Pinentry opens.
As in this case, where the indicated "Generate New Keys" button was used on a blocked card.