From: Robert Brown <robert.brown@gmail.com>
To: 7808@debbugs.gnu.org
Subject: bug#7808: 23.2; nntp authinfo bug with async gnus
Date: Sat, 8 Jan 2011 17:50:27 -0500 [thread overview]
Message-ID: <AANLkTik101e3mqgsQ9oG96AWV8Cce55OhxDWc=OFKDuQ@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 7711 bytes --]
This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.
Your bug report will be posted to the bug-gnu-emacs@gnu.org mailing list,
and to the gnu.emacs.bug news group.
Please describe exactly what actions triggered the bug
and the precise symptoms of the bug. If you can, give
a recipe starting from `emacs -Q':
I use GNUS to read Usenet news with the following setting:
(setq gnus-local-domain "bibliotech.com"
gnus-local-organization "Bibliotech"
gnus-select-method '(nntp "news.speakeasy.net"))
(setq gnus-article-save-directory (expand-file-name "~/News")
gnus-asynchronous t ; fetch articles in the background
gnus-check-new-news t
gnus-emphasis-alist '() ; turn off smiley processing
gnus-large-newsgroup 500
gnus-local-timezone "EST"
gnus-novice-user t
gnus-read-active-file nil
gnus-save-all-headers t
gnus-save-killed-list nil ; XXXX: will it work?
gnus-treat-display-smileys nil)
I select a news group in the *Group* buffer, then read a couple of
articles. Invariably, GNUS hangs with message "Waiting for async
article". If I evaluate
(setq nntp-record-commands t)
and modify the nntp-record-command function to print the process name of
the connection it's sending commands to, I see something like this in
the *nntp-log* buffer:
20110108T171746.825 news.speakeasy.net nntpd MODE READER
20110108T171749.813 news.speakeasy.net nntpd NEWGROUPS 110108 212159 GMT
20110108T171749.835 news.speakeasy.net nntpd AUTHINFO USER
bbrown@speakeasy.net
20110108T171749.854 news.speakeasy.net nntpd AUTHINFO PASS XXXXXXXX
20110108T171749.927 news.speakeasy.net nntpd NEWGROUPS 110108 212159 GMT
20110108T171750.459 news.speakeasy.net nntpd LIST ACTIVE rec.woodworking
20110108T171751.079 news.speakeasy.net nntpd LIST ACTIVE rec.woodworking
20110108T171751.080 news.speakeasy.net nntpd LIST ACTIVE gnu.utils.help
20110108T171751.081 news.speakeasy.net nntpd LIST ACTIVE gnu.utils.bugs
...
20110108T171751.088 news.speakeasy.net nntpd LIST ACTIVE
comp.programming.threads
20110108T171751.088 news.speakeasy.net nntpd LIST ACTIVE comp.arch
20110108T171751.089 news.speakeasy.net nntpd LIST ACTIVE comp.ai
20110108T171811.659 news.speakeasy.net nntpd GROUP comp.lang.python
20110108T171826.697 news.speakeasy.net nntpd ARTICLE 714484
20110108T171827.387 news.speakeasy.net nntpd<1> MODE READER
20110108T171827.407 news.speakeasy.net nntpd<1> GROUP comp.lang.python
20110108T171827.408 news.speakeasy.net nntpd<1> ARTICLE 714514
20110108T171827.426 news.speakeasy.net nntpd AUTHINFO USER
bbrown@speakeasy.net
20110108T171827.447 news.speakeasy.net nntpd AUTHINFO PASS XXXXXXXX
20110108T171827.467 news.speakeasy.net nntpd<1> ARTICLE 714514
20110108T171827.485 news.speakeasy.net nntpd AUTHINFO USER
bbrown@speakeasy.net
20110108T171827.504 news.speakeasy.net nntpd AUTHINFO PASS XXXXXXXX
20110108T171827.523 news.speakeasy.net nntpd<1> ARTICLE 714514
20110108T171827.543 news.speakeasy.net nntpd AUTHINFO USER
bbrown@speakeasy.net
20110108T171827.568 news.speakeasy.net nntpd AUTHINFO PASS XXXXXXXX
20110108T171827.586 news.speakeasy.net nntpd<1> ARTICLE 714514
20110108T171827.604 news.speakeasy.net nntpd AUTHINFO USER
bbrown@speakeasy.net
20110108T171827.620 news.speakeasy.net nntpd AUTHINFO PASS XXXXXXXX
20110108T171827.637 news.speakeasy.net nntpd<1> ARTICLE 714514
The code in nntp.el is getting NNTP responses that request authorization
when requesting article 714514 on the second NNTP connection (nntpd<1>),
but it's incorrectly providing authinfo on the first NNTP connection
(nntpd).
There's a workaround. I can add "force yes" to the entry in ~/.authinfo for
my
news server. If I do this, the nntp code unconditionally sends authinfo
when making a new connection. The nntp logging output looks like the
following and async article reading works:
20110108T171354.196 news.speakeasy.net nntpd MODE READER
20110108T171354.236 news.speakeasy.net nntpd AUTHINFO USER
bbrown@speakeasy.net
20110108T171354.254 news.speakeasy.net nntpd AUTHINFO PASS XXXXXXXX
20110108T171356.578 news.speakeasy.net nntpd NEWGROUPS 110108 212159 GMT
20110108T171357.205 news.speakeasy.net nntpd LIST ACTIVE rec.woodworking
20110108T171357.700 news.speakeasy.net nntpd LIST ACTIVE rec.woodworking
20110108T171357.701 news.speakeasy.net nntpd LIST ACTIVE gnu.utils.help
...
20110108T171357.706 news.speakeasy.net nntpd LIST ACTIVE
comp.programming.threads
20110108T171357.706 news.speakeasy.net nntpd LIST ACTIVE comp.arch
20110108T171357.707 news.speakeasy.net nntpd LIST ACTIVE comp.ai
20110108T171424.732 news.speakeasy.net nntpd GROUP comp.lang.python
20110108T171428.314 news.speakeasy.net nntpd XOVER 715333-715335
20110108T171501.534 news.speakeasy.net nntpd ARTICLE 714484
20110108T171503.746 news.speakeasy.net nntpd<1> MODE READER
20110108T171503.769 news.speakeasy.net nntpd<1> AUTHINFO USER
bbrown@speakeasy.net
20110108T171503.790 news.speakeasy.net nntpd<1> AUTHINFO PASS XXXXXXXX
20110108T171503.865 news.speakeasy.net nntpd<1> GROUP comp.lang.python
20110108T171503.866 news.speakeasy.net nntpd<1> ARTICLE 714514
20110108T171504.978 news.speakeasy.net nntpd<1> ARTICLE 714485
20110108T171505.276 news.speakeasy.net nntpd<1> ARTICLE 714496
20110108T171505.883 news.speakeasy.net nntpd<1> ARTICLE 714486
20110108T171506.004 news.speakeasy.net nntpd<1> ARTICLE 714493
20110108T171506.115 news.speakeasy.net nntpd<1> ARTICLE 714495
20110108T171506.535 news.speakeasy.net nntpd<1> ARTICLE 714572
...
If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
`bt full' and `xbacktrace'.
For information about debugging Emacs, please read the file
/local/software/package/emacs-23.2/share/emacs/23.2/etc/DEBUG.
In GNU Emacs 23.2.1 (i686-pc-linux-gnu)
of 2010-08-16 on ugg
configured using `configure '--prefix=/local/software/package/emacs-23.2'
'--without-x''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: C
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: C
value of $LANG: en_US.UTF-8
value of $XMODIFIERS: nil
locale-coding-system: utf-8-unix
default enable-multibyte-characters: t
Major mode: Lisp Interaction
Minor modes in effect:
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
Recent input:
ESC [ > 1 ; 2 3 0 5 ; 0 c ESC x r e p o r t TAB RE
T
Recent messages:
("emacs")
Load-path shadows:
None found.
Features:
(shadow sort mail-extr message ecomplete rfc822 mml easymenu mml-sec
password-cache mm-decode mm-bodies mm-encode mailcap mail-parse rfc2231
rfc2047 rfc2045 qp ietf-drums mailabbrev nnheader gnus-util netrc
time-date mm-util mail-prsvr gmm-utils wid-edit mailheader canlock sha1
hex-util hashcash mail-utils warnings emacsbug slime-autoloads cl cl-19
ediff-hook vc-hooks lisp-float-type lisp-mode register page menu-bar
rfn-eshadow timer jit-lock font-lock syntax facemenu font-core frame
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev loaddefs button minibuffer faces cus-face files text-properties
overlay md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process multi-tty emacs)
[-- Attachment #2: Type: text/html, Size: 11169 bytes --]
next reply other threads:[~2011-01-08 22:50 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-08 22:50 Robert Brown [this message]
[not found] <mailman.0.1294540232.18939.bug-gnu-emacs@gnu.org>
2011-01-11 17:31 ` bug#7808: 23.2; nntp authinfo bug with async gnus Lars Magne Ingebrigtsen
2011-01-24 2:46 ` Lars Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='AANLkTik101e3mqgsQ9oG96AWV8Cce55OhxDWc=OFKDuQ@mail.gmail.com' \
--to=robert.brown@gmail.com \
--cc=7808@debbugs.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).