On Fri 2016-10-14 16:56:37 -0400, OmegaPhil wrote:
> On 14/10/16 00:28, Daniel Kahn Gillmor wrote:
>> On Thu 2016-10-13 14:09:16 -0400, OmegaPhil wrote:
>>> As soon as I did a killall to have gpg-agent load the new
>>> configuration and try again, it worked - I know that gpg2 stuff has
>>> updated recently, and my uptime is ~11d, so perhaps the update scripts
>>> don't kill off gpg-agent when theres some incompatible change?
>> That's right, the package upgrade scripts make no attempt to restart
>> long-running user processes, for reasons i suspect you can imagine :)
>> Can you review /var/log/dpkg.log to see what versions of gpg-agent you
>> might have been running initially?  I'm glad it's working for you now,
>> anyway, though i'm still in the dark as to why it wasn't working for you
>> before.
> Latest mentions of gnupg-agent:
> =================================================
> /var/log/dpkg.log:2016-10-02 08:11:27 upgrade gnupg-agent:amd64 2.1.11-7 
> 2.1.15-3

You wrote ~11d on the 13th.  This upgrade is from the 2nd, ~11d before
the report.  Can you tell me whether this upgrade happend before or
after the boot that led you into the 11d uptime?  If it happened after
then yes, you were most likely running the older gpg-agent without
restarting it, which would explain the failures you saw.

fwiw, gpg should provide warning messages to stderr if it discovers it's
talking to an older agent, but if you only accessed it through enigmail
maybe those warning messages weren't propagated through to where you
could easily see them.


Attachment: signature.asc
Description: PGP signature

Reply via email to