Thanks, I put it in.

It seems you hit the wrong forum, sorry.

I can confirm this as a problem in gpg2, which behaves badly in the "pinentry
canceled" case:

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:

Now this is getting interesting, and curious. I can not reproduce the problem
here, "grep GPG_ERR_ file-for-marcus | gawk -f mkerrcodes.awk" works fine and
produces a syntactically correct mkerrcodes.h

This is a splitting failure. The awk script should split a string like "9
GPG_ERR_EBADF" between the number and the string. To proceed, I need to see the
file _mkerrcodes.h after it is processed by CPP:

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,

I checked this in:

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.

Fixed for trustlist_next as well.

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

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 think I addressed this with revision 1180. It is easy to add more fallback
types, although I stuck to socklen_t only for now. I will check if I can reach
some of the original submitters for testing.

Yeah, I agree that we need to generate it with configure.

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!

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).

Fixed with the following change in SVN (r4209). Thanks for the report!

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.

Fixed in SVN, will be in 0.6.11. Thanks!

Fixed in SVN, will be in 0.6.11. Thanks, Marcus.

Moved to
http://wald.intevation.org/tracker/index.php?func=detail&aid=168&group_id=13&atid=134

Closing this report. If still a problem, please provide more information, like
which link you tried and where you found it.

We switched the thread support model in the meantime. You should not have this
problem anymore.

New releases are signed by a new key.

Please check out the documentation or ask for help on the gnupg-user mailing
list. There are several ways to do this, and which one is best depends on the
circumstances.

Sometimes there are intermittent problems with the ftp server. Works now,
though. Sorry for the inconvenience.

You are calculating the MD5 sum, while you should calculate the SHA-1 sum.
Closing the report.

Works now. Unfortunately, sometimes there are intermittent problems with the
server. Sorry for the inconvenience.