Done for 2.0.13:

This looks pretty much like a pc/sc problem. Please shutdown pcscd and use the
internal CCID driver. With PC/SC we don't have any control over the USB - we
don't even know what this is.

I checked this again and can't replicate this. The file is only written if the
status of the slot changed - independent of any client connection or the use of
SCD SERIALNO. If you lo updating slot 0 status: 0x0000->0x0007 (0->1)ok a the
logs (no options needed) you can clearly see that:

More info:

• scd killscd works when in the replug-without-hibernate case, for hibernate, a restart of pcscd is needed (probably not a scd problem).
• when I don't issue any commands to scd while the reader is unplugged, I can re-plug it anywhere (same or different usb port) and scd recognises this as a USABLE->ACTIVE->NOCARD->USABLE transition chain
• when I issue a SERIALNO command while the reader is unplugged, I get "Card Error" back (sitenote: shouldn't that be a ERR_NO_CARD_READER?) and that one sticks until a KILLSCD.
• this is not the case for other commands (tested: GETINFO version).

In IRC, weasel just told me that this output is just fine. He is right, since
doc/DETAILs says, there is no escaping for --fixed-list-mode.

GPA works fine since it's full of sentinels blocking reentrance into the
reloading code, which I assume is triggered by the scdaemon behaviour
described. In addition, GPA causes the whole stack to wake up periodically to
reload data that didn't change. That's not nice for laptop users and
contributes to Global Warming :)

Marcus, please apply that.

I see that this is a bit annoying. However I don't see the real problem. GPA
works just fine.

We should eventually do something about it. The problem is that you remove the
device and after plugging it in it is considered by the OS as a new device.
This also depends on the Os used and whether PC/SC, ctAPI or the internalCCID
driver is used.

The parser from libassun accepts lowercase variants. That is convenience
feature when working on the commandline with the assuan protocol. It should
never be used in any code. Attribute names are case-sensitive.

scd getinfo version

D 2.0.13-svn5059
$ ./src/gpa --version
gpa 0.9.0-svn996

Any chance this gets applied?

D99: 234_0001-Don-t-mark-properties-as-translatable.patch

Applied. Thanks.

D98: 233_doc-sexp.diff

The translation in zh_TW.po looks good, but the one in zh_CN.po doesn't. It
contains the kanji sequence "删除" (U+5220, U+9664) which is very close to "削
除" (U+524a, U+9664, "remove" in Japanese) in shape.

The greek translation is anywat marked as fuzz. I also marked the Spanish one
fuzzy. The two Chinese translations seem right to me - at least the two strings
don't look to similar.

D97: 232_po-typo.diff

That is no bug but required by the Assuan protocol:

Thanks, I put it in (rev206).

In GPGME, I made some changes to libassuan to avoid the need for sleeping in all
asynchronous cases (these have yet to be backported into libassuan proper). The
only place where it is left is process_request, which is supposed to be
synchronous. But I wonder if process_request can't do with just setting the
socket to blocking (if it isn't already).

I will have access to a MacOS system soon and will take care of ttyname_r then.
Leaving this open as a reminder until then.

I put in a patch similar to that (g_malloc0 was now unnecessary, and I left in
the GMALLOC_SIZE macro). Thanks for taking the time to reporrt this.

Marcus, I think we can close this now.

Can someone please check this?

ping

2.0.12 has been released. Patch for 1.4.9 is available.

I recall that this has been applied; please check and close this bug.

2.0.12 has been released.

Fixed in SVN using

We won't do any changes to 1.4 anymore. You need t wait for 1.5; sorry.

I have just created a new key and gpg crashed. I believe it could be a problem
somewhere else. Most probably incompatibility.

You were right, of course! Thanks for the tipp, which revealed it immediately.
Please close this ticket.