I did a re-installation of the software without any further problems. So it works without errors now.
Thank you for your spupport!

Please, a bit more details

I have sympathy with you, and if gpgme_data_seek were the only user of off_t in
the GPGME API, there would be some force behind your suggestion. However, it
isn't, and I don't think that keeping around multiple interfaces for essentially
the same function is useful in the long run. That said, I have two things that
may help you:

Oops, I accidentially deleted iwm's message accompanying the attachment when
trying to remove my own duplicate. Sorry for that. Here is his original
message in full, you can also find it at:

Hi iwm,

AC_HEADER_TIME is only useful if sys/time.h and time.h shall both be included,
but sys/time.h includes time.h already *and* time.h is not protected against
double inclusion.

Marcus can you please check whether we should use AC_HEADER_TIME and see what
header to include for time.h. Our requirement for unistd.h is just fine: any
toolkit aiming for at least a bit of POSIX compliance should come with one.

Fixed for trustlist_next as well.

Daiki Ueno confirms this fix but asks whether this is also needed for
trustlist_next.

I think that is fixed in revision 1183 with this change:

I am running FreeBSD 4.8-RELEASE. It is running on a Intel Celeron 900MHz
Gateway computer. I have gnupg-1.4.5 and gpgme-1.1.2 installed from source.

Thanks for the logs. Unfortunately, they don't reveal any secrets. The errno
35 is bogus, because the write() succeeded, so errno is not valid.

I have uploaded to files. 139_bad and 139_good. 139_bad is a log when BADSIG
is returned and 139_good is a log of the same message that return a good signature.

Thanks for reporting this. There are a couple such issues where gnupg does not
issue an error message, and thus the operation will silently fail in GPGME as
well. In the past there used to be some heuristics in place which tried to
catch such situations, but they were causing other problems, so they were not
much of an improvement, and for 1.x I removed most of them.

I fixed this in CVS. Thanks for reporting it!

Might this be the reason that we somewhere have a complaint on Sylpheed eating
up the memory?

D29: 90_gpgme_log_errno.patch

Hi Michael,

What level of GPGME_DEBUG do I need to use to get the output you are looking for?

That is because as a Provisional User (which is the default) he can only comment
on his own bugs. Michael: I have set you to regular user, so you should now be
able to comment.

The reporter of the problem in S-Claws bugtracker, Michael Hughes, registered
here (mdh) but he says he can't comment on this issue. Anything he could do?

That's really weird. Maybe the user could expand the DEBUG output that prints
the -1 return from write() to also print the strerror (saved_errno) to see what
the failure is (this should really be in there, but I didn't yet get to clean up
the debug output to be more informative).

Hopefully fixed with this change, but I can't test it:

Today, all checks passed. Without further information about the gpgsm version
used, we can't do anything about it. Closing the report.

Closing this report. No feedback for a year, and no similar reports.

This is by design. In general a standard location is the best
solution. However for testing etc a way to override it is usefule.
Thus we still support gpgProgram to locate the gpg binary.

Not a bug and no reason to change it.

We have by now created the gpg4win project, which contains binaries not only for gnupg and gpgme, but also for a couple of other packages. Please see www.gpg4win.org. Unfortunately, it is not easy to extract just the gpgme DLL from the package, but it is automatically installed if you install gpa or sylpheed. Not sure if this is sufficient for you.

Thanks for the report.

Andreas, can you please try out the current GPGME CVS version, either HEAD or the 1-0-branch? There was a problem that could under some circumstances stall or hang GPGME, because it would call read() on a non-readable file descriptor. You want this change:

The bug is against very old versions of GPGME. The key
cache has since been removed entirely.