From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4)
Description of problem:
Posting a newsgroup, such as "pl.test"
results in a lisp error because rfc2047-encodable-p
encounters a lisp symbol instead of a list.
It probably occurs for any non-standard encoding
setting, pl.test will make GNUS happen to use
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Post test posting to "pl.test"
Actual Results: Lisp error. The posting actually goes out, but the posting
buffer sits there and you have to kill it off manually.
This confused my wife.
Expected Results: The posting should have gone out without any lisp
If we are going to ship a different version of GNUS that that
contained in the stock emacs sources, we should at least test
simple things like posting to non-english newsgroups.
Here is the LISP backtrace btw:
Signaling: (wrong-type-argument listp iso-8859-2)
It has been tested with non-English newsgroups (Norwegian ones :). Can you check
if emacs 21 (available from http://people.redhat.com/teg/emacs/) solves the problem?
This causes a complete hang of my wife's computer when
GNUS is started. This was under X.
We rebooted cleanly, and from a plain text console I tried
again. Same thing, starting GNUS causes a full system hang.
Wouldn't it be easier just to fix the code in the 20.7 SRPM
so that the rfc2047-encodable-p elisp defun gets the correct
types? ... Just an idea... When I traced the code it seems
that the "newgroup regexp" --> "charset" mapping was just using
Athlon 1700+ XP
all kernel/glibc/etc. updates installed
>This causes a complete hang of my wife's computer when
>GNUS is started.
That sounds like a kernel bug to me. Or an X bug. Not an
And if I would keep reading, I would notice that it is definitely
a kernel bug.
Still the case with modern kernels Dave ? and if so is it emacs running the box
out of ram?
No, turned out to be dodgy ram in my wife's Athlon.