We are pleased to announce version 0.4.5 of GnuPG Made Easy,
a library designed to make access to GnuPG easier for applications.
It may be found in the file (about 698 KB compressed)
ftp://ftp.gnupg.org/gcrypt/alpha/gpgme/gpgme-0.4.5.tar.gz.
It should soon appear on the mirrors listed at
http://www.gnupg.org/mirrors.html.
Bug reports and requests for assistance should be sent to
gnupg-devel@gnupg.org.
The md5sum checksums for this distibution are
24582f881113a9e4e76b70e63fbf5132 gpgme-0.4.4-0.4.5.diff.gz
f04bc4feb818f55107910d17273adf98 gpgme-0.4.5.tar.gz
b68700dbb966419cb0b5b8d9dc461afc gpgme-0.4.5.tar.gz.sig
PLEASE NOTE: This is an unstable development version for testing.
The latest stable release is 0.3.16 and available from
ftp://ftp.gnupg.org/gcrypt/gpgme/.
Marcus Brinkmann
mb@g10code.de
Noteworthy changes in version 0.4.5 (2004-03-07)
------------------------------------------------
* GPGME is now compiled with LFS (large file support) by default.
This means that _all_ programs using GPGME must be compiled with
LFS support enabled by default. You can do this easily with
autoconf, by using the AC_SYS_LARGEFILE macro. Or you can do this
without autoconf by defining the preprocessor symbol
_FILE_OFFSET_BITS to 64 (by passing the -D_FILE_OFFSET_BITS=64 to
the C compiler command line, or by defining this preprocessor
symbol before including any system header files). For more
details, read the section on LFS in the manual.
Up to now, it was undocumented that GPGME was not using LFS.
But the public interfaces use off_t, and file descriptors are
exchanged between the application and GPGME. This was an oversight,
and bound to cause troubles in the future.
Writing GPGME as a dual mode library that seamlessly supports LFS
while keeping backwards compatibility is possible, but does not
solve the problem: Many applications already expect GPGME to have
LFS (they are compiled with off_t being a 64bit value). This is true
in particular for the popular Gtk+ and Qt programs.
So, although this is an ABI (but not an API) break, we will not
change the library version to reflect that. Because the interfaces
affected are probably not used yet in any GPGME 0.4 based
application, we don't expect any real failures from this change.
In fact, applications already using LFS will have some subtle bugs
fixed.
However, if you encounter an application using GPGME 0.4.x that
does _not_ use LFS by default (off_t is a 32bit value), _and_
uses at least one of the functions gpgme_data_seek,
gpgme_data_new_from_filepart, or a gpgme_data_seek_cb_t with
gpgme_data_new_from_cbs, then indeed this library will be ABI
incompatible with the program. As said above, we don't believe
such a program exists. If we are in error, then you have two
options: As a quick hack, you can configure GPGME with the
--disable-largefile option. This will revert the change, and GPGME
will not use LFS. However, GPGME will be incompatible with
programs that expect GPGME to use LFS. All applications are
required to use LFS when using GPGME, so this is only good as a
temporary local work-around.
The other option is to change the versioning of the library and
recompile all applications. We have reserved a special version of
the library for that, so you can do that without expecting a
version clash in the future. Furthermore, everyone who does this
will agree on the version to use (this is important for
distribution makers). Read the comment in configure.ac (before
LIBGPGME_LT_AGE) if you want to do this. Please don't do this
blindly: As stated above, we think it is unlikely this measure is
needed. Still, it is there if necessary. If in doubt, contact us
and we will give our advise for your specific situation.
* New key listing mode GPGME_KEYLIST_MODE_VALIDATE for validation of
the listed keys.
* New interface gpgme_cancel() that can be used to cancel
asynchronous operations.
* Interface changes relative to the 0.4.4 release:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
gpgme_data_seek_cb_t CHANGED: off_t is now a largefile type.
gpgme_data_seek CHANGED: off_t is now a largefile type.
gpgme_data_new_from_filepart CHANGED: off_t is now a largefile type.
GPGME_KEYLIST_MODE_VALIDATE NEW
gpgme_cancel NEW
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
a library designed to make access to GnuPG easier for applications.
It may be found in the file (about 698 KB compressed)
ftp://ftp.gnupg.org/gcrypt/alpha/gpgme/gpgme-0.4.5.tar.gz.
It should soon appear on the mirrors listed at
http://www.gnupg.org/mirrors.html.
Bug reports and requests for assistance should be sent to
gnupg-devel@gnupg.org.
The md5sum checksums for this distibution are
24582f881113a9e4e76b70e63fbf5132 gpgme-0.4.4-0.4.5.diff.gz
f04bc4feb818f55107910d17273adf98 gpgme-0.4.5.tar.gz
b68700dbb966419cb0b5b8d9dc461afc gpgme-0.4.5.tar.gz.sig
PLEASE NOTE: This is an unstable development version for testing.
The latest stable release is 0.3.16 and available from
ftp://ftp.gnupg.org/gcrypt/gpgme/.
Marcus Brinkmann
mb@g10code.de
Noteworthy changes in version 0.4.5 (2004-03-07)
------------------------------------------------
* GPGME is now compiled with LFS (large file support) by default.
This means that _all_ programs using GPGME must be compiled with
LFS support enabled by default. You can do this easily with
autoconf, by using the AC_SYS_LARGEFILE macro. Or you can do this
without autoconf by defining the preprocessor symbol
_FILE_OFFSET_BITS to 64 (by passing the -D_FILE_OFFSET_BITS=64 to
the C compiler command line, or by defining this preprocessor
symbol before including any system header files). For more
details, read the section on LFS in the manual.
Up to now, it was undocumented that GPGME was not using LFS.
But the public interfaces use off_t, and file descriptors are
exchanged between the application and GPGME. This was an oversight,
and bound to cause troubles in the future.
Writing GPGME as a dual mode library that seamlessly supports LFS
while keeping backwards compatibility is possible, but does not
solve the problem: Many applications already expect GPGME to have
LFS (they are compiled with off_t being a 64bit value). This is true
in particular for the popular Gtk+ and Qt programs.
So, although this is an ABI (but not an API) break, we will not
change the library version to reflect that. Because the interfaces
affected are probably not used yet in any GPGME 0.4 based
application, we don't expect any real failures from this change.
In fact, applications already using LFS will have some subtle bugs
fixed.
However, if you encounter an application using GPGME 0.4.x that
does _not_ use LFS by default (off_t is a 32bit value), _and_
uses at least one of the functions gpgme_data_seek,
gpgme_data_new_from_filepart, or a gpgme_data_seek_cb_t with
gpgme_data_new_from_cbs, then indeed this library will be ABI
incompatible with the program. As said above, we don't believe
such a program exists. If we are in error, then you have two
options: As a quick hack, you can configure GPGME with the
--disable-largefile option. This will revert the change, and GPGME
will not use LFS. However, GPGME will be incompatible with
programs that expect GPGME to use LFS. All applications are
required to use LFS when using GPGME, so this is only good as a
temporary local work-around.
The other option is to change the versioning of the library and
recompile all applications. We have reserved a special version of
the library for that, so you can do that without expecting a
version clash in the future. Furthermore, everyone who does this
will agree on the version to use (this is important for
distribution makers). Read the comment in configure.ac (before
LIBGPGME_LT_AGE) if you want to do this. Please don't do this
blindly: As stated above, we think it is unlikely this measure is
needed. Still, it is there if necessary. If in doubt, contact us
and we will give our advise for your specific situation.
* New key listing mode GPGME_KEYLIST_MODE_VALIDATE for validation of
the listed keys.
* New interface gpgme_cancel() that can be used to cancel
asynchronous operations.
* Interface changes relative to the 0.4.4 release:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
gpgme_data_seek_cb_t CHANGED: off_t is now a largefile type.
gpgme_data_seek CHANGED: off_t is now a largefile type.
gpgme_data_new_from_filepart CHANGED: off_t is now a largefile type.
GPGME_KEYLIST_MODE_VALIDATE NEW
gpgme_cancel NEW
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~