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>