Barry A. Warsaw wrote:
However, I've noticed one incompatibility so far. I have some
files
which are encrypted with GnuPG 1.0.6. In the non-MULE version of
21.4.6 (i.e. built with no configure options), I can simply visit the
file, XEmacs prompts for the encryption key which I enter, and I'm
presented with the decrypted file in a buffer.
However, when configured with --with-mule, after entering the
encryption key, the decrypt fails and I'm left with this in the
buffer:
gpg: fatal: zlib inflate problem: incorrect data check^Msecmem usage: 2272/2432 bytes in
6/7 blocks of pool 2432/16384
(single character ^M replaced for transport)
Actually everything from the ^M onward is displayed as an elipsis.
I've confirmed that my recent updating of all packages is not the
cause because I rebuild from source without MULE and I can still
decrypt the file. It's definitely a breakage --with-mule.
Anybody have any ideas? Known bug? Googling didn't turn up much
useful, except a seemingly unrelated couple of messages in the gnupg
lists.
Presumably it's a file-coding problem, i.e. it still occurs if you use
--with-file-coding instead of --with-mule.
If so, whichever "auto-decode" package is involved (mailcrypt,
jka-compr, ...) should probably bind coding-system-for-read and/or
coding-system-for-write to 'binary.
Also, it can usually be worked around by the user by setting
process-coding-system-alist, e.g.
(push '("/.*" . binary) process-coding-system-alist)
--
Glynn Clements <glynn.clements(a)virgin.net>