During a rebuild of all Debian packages in a clean sid chroot (and cowbuilder+pbuilder)
the build failed with the following error. Please note that we use our research
compiler tool-chain (using tools from the cbmc package), which permits extended
reporting on type inconsistencies at link time.

[...]
libtool: link:  gcc -shared  -fPIC -DPIC  .libs/gkm-secret-standalone.o  -Wl,--whole-archive ./.libs/libgkm-secret-store.a ./.libs/libgkm.a -Wl,--no-whole-archive  -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lgcrypt  -O2 -Wl,-z -Wl,relro -Wl,-O1 -Wl,-z -Wl,defs -Wl,--as-needed -pthread   -pthread -Wl,-soname -Wl,gkm-secret-store-standalone.so -Wl,-version-script -Wl,.libs/gkm-secret-store-standalone.ver -o .libs/gkm-secret-store-standalone.so

error: conflicting function declarations "gkm_secret_binary_read"
old definition in module gkm-secret-binary file pkcs11/secret-store/gkm-secret-binary.c line 850
signed int (struct _GkmSecretCollection *collection, struct _GkmSecretData *sdata, const void *data, unsigned long int n_data)
new definition in module gkm-secret-collection file pkcs11/secret-store/gkm-secret-binary.h line 29
GkmDataResult (struct _GkmSecretCollection *, struct _GkmSecretData *, const void *, unsigned long int)

Even though the compiler may actually implement the enum via a signed integer,
there is no such guarantee in the C standard. Even more problematic, however, is
the fact that function calling gkm_secret_binary_read will rely on the return
value being one of the enum values - but no such guarantee is provided by the
implementation.

Yet skimming the code it seems the implementation does use GkmDataResult
throughout, so likely just its declaration in gkm-secret-binary.c is wrong.

Best,
Michael