Gnus v5.2.37 is released

Gnus v5.2.37 is released

[Lars Magne Ingebrigtsen]

Bug fixes.

Get it from <URL:http://www.ifi.uio.no/~larsi/gnus.tar.gz> or 
"ftp.ifi.uio.no:/pub/emacs/gnus/".

ChangeLog since last release:

Fri Jul 19 02:12:58 1996  Lars Magne Ingebrigtsen  <larsi@ifi.uio.no>

	* gnus.el: Gnus v5.2.37 is released.

Fri Jul 19 00:31:22 1996  Lars Magne Ingebrigtsen  <larsi@ifi.uio.no>

	* gnus.el (gnus-subscribe-newsgroup): Add new groups to top-level
	topic. 
	(gnus-group-make-archive-group): Add a to-address group param.

	* gnus-topic.el (gnus-topic-hide-topic): Doc fix.
	(gnus-topic-select-group): Doc fix.
	(gnus-topic-rename): Keep point nearby.

	* gnus.el (gnus-group-goto-group): More efficient (and more
	correct) implementation.
	(gnus-group-sort-function): Doc fix.
	(gnus-group-edit-buffer): Changed to defvar.
	(gnus-group-edit-group-done): Use new name.
	(gnus-group-edit-group): Include name of group in grup buffer
	name. 

	* nnfolder.el (nnfolder-save-mail): Handle babylish ">From"
	lines. 
	* nnmbox.el (nnmbox-request-accept-article): Ditto.

Thu Jul 18 23:50:31 1996  Lars Magne Ingebrigtsen  <larsi@ifi.uio.no>

	* nnmail.el (nnmail-move-inbox): Don't substitute in command
	name. 

	* gnus-xmas.el (gnus-xmas-modeline-glyph): New variable.

Thu Jul 18 16:35:22 1996  Lars Magne Ingebrigtsen  <lars@eyesore.no>

	* custom.el (custom-facep): Didn't work under non-X Emacs.

Thu Jul 18 00:02:32 1996  Lars Magne Ingebrigtsen  <larsi@hler.ifi.uio.no>

	* nntp.el (nntp-open-telnet): Use more permissive regexps.

	* gnus-uu.el (gnus-uu-uustrip-article): `cd' to make gnus-uu work
	under NT.

Mon Jul 15 18:11:13 1996  Jan Vroonhof  <vroonhof@math.ethz.ch (Jan Vroonhof)>

	* smiley.el (smiley-regexp-alist): Don't match important parts of URLs
	(smiley-nosey-regexp-alist): New variable.

Wed Jul 17 23:48:50 1996  Mark Borges  <mdb@cdc.noaa.gov>

	* messagexmas.el (nnheader): Required.

Wed Jul 17 02:02:25 1996  Michael Cook  <mcook@cognex.com>

	* nnmail.el (nnmail-split-abbrev-alist): New default.

Wed Jul 17 00:27:13 1996  Lars Magne Ingebrigtsen  <larsi@hler.ifi.uio.no>

	* message.el (message-mode-abbrev-table): New variable. 
	(message-mode): New variable.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: Gnus v5.2.37 is released

[Mark Borges]

>> On 19 Jul 1996 02:13:16 +0200,
>> Lars Magne Ingebrigtsen(lars) wrote:

lars> ChangeLog since last release:

lars> Thu Jul 18 23:50:31 1996  Lars Magne Ingebrigtsen  <larsi@ifi.uio.no>
lars> 	* nnmail.el (nnmail-move-inbox): Don't substitute in command
lars> 	name. 
lars> 	* gnus-xmas.el (gnus-xmas-modeline-glyph): New variable.

??
  $ pwd
  /tmp/mdb/gnus-5.2.37/lisp
  $ grep modeline-glyph ChangeLog
          * gnus-xmas.el (gnus-xmas-modeline-glyph): New variable.
  $ grep modeline-glyph *.el
  $

:-(. I thought this meant we'd see a tiny Gnu creature in the
modeline, but I guess it fell through the proverbial crack...

-- 
  -mb-

Re: Gnus v5.2.37 is released

[Lars Magne Ingebrigtsen]

Mark Borges <mdb@cdc.noaa.gov> writes:

> :-(. I thought this meant we'd see a tiny Gnu creature in the
> modeline, but I guess it fell through the proverbial crack...

I wrote the code, and then I though -- "Hang on a minute.  This is the
very tail end of the Gnus 5.2 cycle.  Do I really want to add
potentially buggy silly things now?  Nope."

So it's coming in Red Gnus.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: Gnus v5.2.37 is released

[Jan Vroonhof]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1141 bytes --]


I'm sorry but the wrong version of my smiley pacth got into 5.2.37 :-(
(My fault)

*** smiley.el.orig	Wed Jul 17 23:58:59 1996
--- smiley.el	Fri Jul 19 10:05:03 1996
***************
*** 49,55 ****
      ("\\(:-+\\]+\\)\\W" 1 "FaceGoofy.xpm")
      ("\\(:-*D\\)\\W" 1 "FaceGrinning.xpm")
      ("\\(:-*[)>}»]+\\)\\W" 1 "FaceHappy.xpm")
!     ("\\(:-*[/\\\"]\\)[^\\]" 1 "FaceIronic.xpm")
      ("\\([8|]-*[|Oo%]\\)\\W" 1 "FaceKOed.xpm")
      ("\\([:|]-*#+\\)\\W" 1 "FaceNyah.xpm")
      ("\\(:-*[({]+\\)\\W" 1 "FaceSad.xpm")
--- 49,55 ----
      ("\\(:-+\\]+\\)\\W" 1 "FaceGoofy.xpm")
      ("\\(:-*D\\)\\W" 1 "FaceGrinning.xpm")
      ("\\(:-*[)>}»]+\\)\\W" 1 "FaceHappy.xpm")
!     ("\\(:-*[/\\\"]\\)[^/]" 1 "FaceIronic.xpm")
      ("\\([8|]-*[|Oo%]\\)\\W" 1 "FaceKOed.xpm")
      ("\\([:|]-*#+\\)\\W" 1 "FaceNyah.xpm")
      ("\\(:-*[({]+\\)\\W" 1 "FaceSad.xpm")


-- 
Jan Vroonhof                    http://www.math.ethz.ch/~vroonhof/
Mathematik,                                  vroonhof@math.ethz.ch
HG E16, ETH-Zentrum,                      Tel: +41-1-6325456/25154
Raemistrasse 101, CH-8092 Zuerich.              Fax: +41-1-6321085

GNUS hanging.

[Ralph Loader]

Hi,

A while ago a contacted you about Gnus hanging on entering a newsgroup.
I've found how to reproduce this: post an article with a repeated entry in
the references header.  E.g.,

Path: news.ox.ac.uk!news
From: Ralph Loader <loader@maths.ox.ac.uk>
Newsgroups: ox.test
Subject: Re: where is my message?
Date: 19 Jul 1996 18:14:48 +0100
Organization: Merton College, Oxford.
Lines: 6
Sender: loader@oban.ox.ac.uk
Message-ID: <m1687kmagn.fsf@oban.ox.ac.uk>
References: <31EFAFC6.14C8@maths.ox.ac.uk>
 <31EFAFC6.14C8@maths.ox.ac.uk>
NNTP-Posting-Host: ermine.ox.ac.uk
X-Face: "\DEVKOBazdfo)a[qH[tA@i)|B?QlBd1:5\;#%#Rhqu0,V{SKg"4R4)=}3($4L<SR"}PmC!
 {qN!'4,sL2b)3&szw{2hM`y{r64A9(V*U4}8u7y0*O|89WkYO%&z)\5_~'%CMih>9b!&3|mbBEw>8t
 IgZB?hW`nnzLfO>N(3:ME'x\qB
X-Newsreader: Gnus v5.2.34/XEmacs 19.14
Xref: news.ox.ac.uk ox.test:1547

On re-entering the group, Gnus goes into an infinite loop, entering this
article in the summary buffer:

   [   6: Ralph Loader        ] Re: where is my message?
   [   6: Ralph Loader        ] Re: where is my message?
   [   6: Ralph Loader        ] Re: where is my message?

Hope this helps,

Ralph.

Gnus hanging

[Richard Riley]

I'm frequently on a wireless connection that fails. Gnus hangs if I do a
"g" (or more accurately C-u 5 g) in the group buffer to get new headers
if the link has gone down and come back up again - I assume because of
non valid network stream handles or whatever. What would be the best way
to ensure Gnus closes all network links first and reconnects prior to
the refresh other than quitting or closing/opening from the server
buffer?

regards
r.

Re: Gnus hanging

[Dave Abrahams]

on Wed Jul 06 2011, Richard Riley <rileyrg-AT-googlemail.com> wrote:

> I'm frequently on a wireless connection that fails. Gnus hangs if I do a
> "g" (or more accurately C-u 5 g) in the group buffer to get new headers
> if the link has gone down and come back up again - I assume because of
> non valid network stream handles or whatever. What would be the best way
> to ensure Gnus closes all network links first and reconnects prior to
> the refresh other than quitting or closing/opening from the server
> buffer?

+1

Long-standing issue for me, too.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Re: Gnus hanging

[Antoine Levitt]

08/07/11 13:14, Dave Abrahams
> on Wed Jul 06 2011, Richard Riley <rileyrg-AT-googlemail.com> wrote:
>
>> I'm frequently on a wireless connection that fails. Gnus hangs if I do a
>> "g" (or more accurately C-u 5 g) in the group buffer to get new headers
>> if the link has gone down and come back up again - I assume because of
>> non valid network stream handles or whatever. What would be the best way
>> to ensure Gnus closes all network links first and reconnects prior to
>> the refresh other than quitting or closing/opening from the server
>> buffer?
>
> +1
>
> Long-standing issue for me, too.

+1 for me also.

I also mentioned in some other thread the problem of suspending a laptop
with a local connection to an IMAP server (I use dovecot, but I guess it
isn't specific to the server on the end). Sometimes the connection will
live on, sometimes it will hang, sometimes it will silently fail and not
show any new messages.

I'm not sure if there's a right way for gnus to react to this sort of
things. Maybe it could listen via dbus to system events such as "link
has gone down/up"? NetworkManager does send some stuff, but I'm not sure
if there's a standard for this.

Re: Gnus hanging

[lee]

Dave Abrahams <dave@boostpro.com> writes:

> on Wed Jul 06 2011, Richard Riley <rileyrg-AT-googlemail.com> wrote:
>
>> I'm frequently on a wireless connection that fails. Gnus hangs if I do a
>> "g" (or more accurately C-u 5 g) in the group buffer to get new headers
>> if the link has gone down and come back up again - I assume because of
>> non valid network stream handles or whatever. What would be the best way
>> to ensure Gnus closes all network links first and reconnects prior to
>> the refresh other than quitting or closing/opening from the server
>> buffer?
>
> +1
>
> Long-standing issue for me, too.

Trying to trace the problem, I've been watching connections with
"netstat -t" and found that gnus hangs when the connection to the news
server is closed.  Gnus reopens the connection and hangs.  I've modified
the entry for the news server, adding `nntp-connection-timeout' for a
timeout of 15 seconds:


(add-to-list 'gnus-secondary-select-methods
	     '(nntp "news1.open-news-network.org"
		    (nntp-connection-timeout 15)))


Because it takes two hours for the connection to time out, I haven't
been able to see if it works yet.  If it doesn't work, an alternative
might be something like "(gnus-demon-add-handler 'gnus-demon-scan-news
10 nil)" to keep the connection open or "(gnus-demon-add-handler
'gnus-demon-close-connections 5 nil)" to close it before it times out,
in which case gnus might gracefully reopen it.

Perhaps you can come up with something similar for your POP3 and IMAP
connections as a workaround?  Closing the connections after a short time
or idle period might work for POP3 and IMAP ...

BTW, see http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9020 .

Re: Gnus hanging

[Richard Riley]

lee <lee@yun.yagibdah.de> writes:

> Dave Abrahams <dave@boostpro.com> writes:
>
>> on Wed Jul 06 2011, Richard Riley <rileyrg-AT-googlemail.com> wrote:
>>
>>> I'm frequently on a wireless connection that fails. Gnus hangs if I do a
>>> "g" (or more accurately C-u 5 g) in the group buffer to get new headers
>>> if the link has gone down and come back up again - I assume because of
>>> non valid network stream handles or whatever. What would be the best way
>>> to ensure Gnus closes all network links first and reconnects prior to
>>> the refresh other than quitting or closing/opening from the server
>>> buffer?
>>
>> +1
>>
>> Long-standing issue for me, too.
>
> Trying to trace the problem, I've been watching connections with
> "netstat -t" and found that gnus hangs when the connection to the news
> server is closed.  Gnus reopens the connection and hangs.  I've modified
> the entry for the news server, adding `nntp-connection-timeout' for a
> timeout of 15 seconds:
>
> (add-to-list 'gnus-secondary-select-methods
> 	     '(nntp "news1.open-news-network.org"
> 		    (nntp-connection-timeout 15)))
>
> Because it takes two hours for the connection to time out, I haven't
> been able to see if it works yet.  If it doesn't work, an alternative

Simpy unplug the network or "sudo ifdown -a"?

Re: Gnus hanging

[lee]

Richard Riley <rileyrg@googlemail.com> writes:

> lee <lee@yun.yagibdah.de> writes:
>> Because it takes two hours for the connection to time out, I haven't
>> been able to see if it works yet.  If it doesn't work, an alternative
>
> Simpy unplug the network or "sudo ifdown -a"?

Well, I didn't want to have different conditions for testing than for
normal operation.  I had started to write a reply to a question Lars had
sent me in reply to the bug report I had sent and was watching the
connections to the two news servers I'm using and experimenting.

The connection to the news server that doesn't require authentication
(gmane) closes after 15 or 20 minutes or so, and gnus brings it back up
just fine when checking for new news and doesn't hang.  The connection
to the other news server which does require authentication stays for two
hours, and though gnus brings it back up again, gnus will hang.

Who knows, interrupting the network connection may be very different
from a connection closing or timing out normally, perhaps especially so
when authentication is involved.


It seems interesting that gnus hangs when authentication is involved and
doesn't hang when authentication is not involved.  If I kept track
correctly, all the other users reporting this problem have it with
connections that do require authentication (POP3 and IMAP).  Now
remember the message about the TLS error showing up in the *Messages*
buffer: Do you see this message, too?

Re: Gnus hanging

[Lars Magne Ingebrigtsen]

lee <lee@yun.yagibdah.de> writes:

> It seems interesting that gnus hangs when authentication is involved and
> doesn't hang when authentication is not involved.  If I kept track
> correctly, all the other users reporting this problem have it with
> connections that do require authentication (POP3 and IMAP).

Yes, that's interesting.  Hm...

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Gnus hanging

[Richard Riley]

Dave Abrahams <dave@boostpro.com> writes:

> on Wed Jul 06 2011, Richard Riley <rileyrg-AT-googlemail.com> wrote:
>
>> I'm frequently on a wireless connection that fails. Gnus hangs if I do a
>> "g" (or more accurately C-u 5 g) in the group buffer to get new headers
>> if the link has gone down and come back up again - I assume because of
>> non valid network stream handles or whatever. What would be the best way
>> to ensure Gnus closes all network links first and reconnects prior to
>> the refresh other than quitting or closing/opening from the server
>> buffer?
>
> +1
>
> Long-standing issue for me, too.

Any info on this or any ideas how to customise something to restart the
connections on a "g"? Its hanging all the time on my netbook when the
wireless is dodgy.

Re: Gnus hanging

[lee]

Richard Riley <rileyrg@googlemail.com> writes:

> Dave Abrahams <dave@boostpro.com> writes:
>
>> on Wed Jul 06 2011, Richard Riley <rileyrg-AT-googlemail.com> wrote:
>>
>>> I'm frequently on a wireless connection that fails. Gnus hangs if I do a
>>> "g" (or more accurately C-u 5 g) in the group buffer to get new headers
>>> if the link has gone down and come back up again - I assume because of
>>> non valid network stream handles or whatever. What would be the best way
>>> to ensure Gnus closes all network links first and reconnects prior to
>>> the refresh other than quitting or closing/opening from the server
>>> buffer?
>>
>> +1
>>
>> Long-standing issue for me, too.
>
> Any info on this or any ideas how to customise something to restart the
> connections on a "g"? Its hanging all the time on my netbook when the
> wireless is dodgy.

Gnus apparently does re-open the connections when they were closed
(timed out). You can see that when watching them with "netstat -t".  Yet
that doesn't seem to help with connections that involve authentication.

So far, I've only found that neither setting nntp-connection-timeout nor
having a deamon like "(gnus-demon-add-handler
'gnus-demon-close-connections 5 nil)" makes any difference.

At the moment, gnus hangs every time I press `g' after it didn't happen
at all for about two days, all for no apparent reason.

It might help to find out what causes the problem if everyone adds their
backtrace[1] to the bug report[2], perhaps with some information added
under what conditions it occurs.


[1]: add "(setq debug-on-quit t)" to your ~/.emacs to get a backtrace
     when pressing C-g
[2]: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9020 --- I guess you
     can mail additional info by sending it to 9020@debbugs.gnu.org


-- 
html messages are obsolete

Re: Gnus hanging

[Lars Magne Ingebrigtsen]

Richard Riley <rileyrg@googlemail.com> writes:

> What would be the best way to ensure Gnus closes all network links
> first and reconnects prior to the refresh other than quitting or
> closing/opening from the server buffer?

`gnus-close-backends' will make Gnus close all the backends, but this
will shut down everything "gracefully".  If the network connections are
so b0rked that even sending "QUIT" without waiting for a response will
hang, I guess it won't help.

But it probably does the trick.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Gnus hanging

[lee]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> `gnus-close-backends' will make Gnus close all the backends, but this
> will shut down everything "gracefully".

And how do you reopen them?

Re: Gnus hanging

[Lars Magne Ingebrigtsen]

lee <lee@yun.yagibdah.de> writes:

> And how do you reopen them?

It happens automatically when you `g'.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/