GNU bug report logs - #16988
24.3.50; emacs -nw -Q --eval '(kill-emacs)' takes 2 seconds unless I hit a key

Previous Next

Package: emacs;

Reported by: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>

Date: Tue, 11 Mar 2014 15:24:01 UTC

Severity: important

Found in version 24.3.50

Done: Stefan Monnier <monnier <at> IRO.UMontreal.CA>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 16988 in the body.
You can then email your comments to 16988 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#16988; Package emacs. (Tue, 11 Mar 2014 15:24:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Nicolas Richard <theonewiththeevillook <at> yahoo.fr>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Tue, 11 Mar 2014 15:24:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50;
 emacs -nw -Q --eval '(kill-emacs)' takes 2 seconds unless I hit a key
Date: Tue, 11 Mar 2014 16:22:21 +0100
With latest trunk:
$ time src/emacs -nw -Q --eval '(kill-emacs)'

real	0m2.064s
user	0m0.030s
sys	0m0.010s

If however I hit a key, emacs exits immediately.

with 24.3 (git commit 3a1ce0685) :
$ time src/emacs -nw -Q --eval '(kill-emacs)'

real	0m0.063s
user	0m0.030s
sys	0m0.012s

The '--eval' part is just there to make emacs exit asap.

Note that replacing -Q with --batch works fine.

-- 
Nico.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16988; Package emacs. (Tue, 11 Mar 2014 17:19:02 GMT) Full text and rfc822 format available.

Message #8 received at 16988 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
Cc: 16988 <at> debbugs.gnu.org
Subject: Re: bug#16988: 24.3.50;
 emacs -nw -Q --eval '(kill-emacs)' takes 2 seconds unless I hit a key
Date: Tue, 11 Mar 2014 19:18:35 +0200
> From: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
> Date: Tue, 11 Mar 2014 16:22:21 +0100
> 
> With latest trunk:
> $ time src/emacs -nw -Q --eval '(kill-emacs)'
> 
> real	0m2.064s
> user	0m0.030s
> sys	0m0.010s

I cannot reproduce this.  I get the same 0.330s time with both current
trunk and Emacs 24.3.  That's on this system:

  eliz <at> fencepost:~/bzr/emacs/trunk$ uname -a
  Linux fencepost.gnu.org 2.6.32-48-server #1trisquel3 SMP Mon Jun 17 20:00:36 UTC 2013 x86_64 GNU/Linux

My crystal ball says that your TERM variable points to xterm, but your
terminal either isn't xterm or doesn't support the kind of queries
that xterm--query on xterm.el uses.  That function indeed waits for 2s
for the terminal to respond. 




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16988; Package emacs. (Tue, 11 Mar 2014 19:09:02 GMT) Full text and rfc822 format available.

Message #11 received at 16988 <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>, 16988 <at> debbugs.gnu.org
Subject: Re: bug#16988: 24.3.50;
 emacs -nw -Q --eval '(kill-emacs)' takes 2 seconds unless I hit a key
Date: Tue, 11 Mar 2014 20:08:21 +0100
Eli Zaretskii <eliz <at> gnu.org> writes:
> I cannot reproduce this.  I get the same 0.330s time with both current
> trunk and Emacs 24.3.  That's on this system:
>
>   eliz <at> fencepost:~/bzr/emacs/trunk$ uname -a
>   Linux fencepost.gnu.org 2.6.32-48-server #1trisquel3 SMP Mon Jun 17 20:00:36 UTC 2013 x86_64 GNU/Linux
>
> My crystal ball says that your TERM variable points to xterm, but your
> terminal either isn't xterm or doesn't support the kind of queries
> that xterm--query on xterm.el uses.  That function indeed waits for 2s
> for the terminal to respond. 

Your crystal ball works well : I use gnome-terminal and that sets TERM
to xterm. I'll have to figure out the best way to fix that. using
TERM=gnome fixes the problem, but I don't know if that's TRT, and I
don't know either where I should set that.  I've read that:
> if [ "$COLORTERM" = "gnome-terminal" ]
> then
>     export TERM=gnome
> fi
to my .bashrc will fix it but it's not pretty.

Thanks.

--
Nico.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16988; Package emacs. (Wed, 12 Mar 2014 10:37:02 GMT) Full text and rfc822 format available.

Message #14 received at 16988 <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>, 16988 <at> debbugs.gnu.org
Subject: Re: bug#16988: 24.3.50;
 emacs -nw -Q --eval '(kill-emacs)' takes 2 seconds unless I hit a key
Date: Wed, 12 Mar 2014 09:59:13 +0100
Eli Zaretskii <eliz <at> gnu.org> writes:
>> $ time src/emacs -nw -Q --eval '(kill-emacs)'
>> 
>> real	0m2.064s
>> user	0m0.030s
>> sys	0m0.010s

> My crystal ball says that your TERM variable points to xterm, but your
> terminal either isn't xterm or doesn't support the kind of queries
> that xterm--query on xterm.el uses.  That function indeed waits for 2s
> for the terminal to respond. 

Since it was not a problem before, I bisected that down to commit:
commit 7e594297002c7bc07083fa8d01552255e831ba2a
Author: W. Trevor King <wking <at> tremily.us>
Date:   Wed Feb 19 23:45:19 2014 -0500

    * lisp/term/xterm.el (xterm--version-handler): Adapt to xterm-280's output.

which changed xterm--version-handler (in lisp/term/xterm.el) in the following way:

-    (when (string-match "0;\\([0-9]+\\);0" str)
-      (let ((version (string-to-number (match-string 1 str))))
+    ;; Since xterm-280, the terminal type (NUMBER1) is now 41 instead of 0.
+    (when (string-match "\\([0-9]+\\);\\([0-9]+\\);0" str)
+      (let ((version (string-to-number (match-string 2 str))))

That has the effect of now matching gnome-terminal's string (it begins
with 1 on my platform).

As a side effect of this, calling "emacsclient -t" from within
gnome-terminal currently acts weird : it shows the wrong buffer for up
to two second and --if you press some keys before the 2 seconds-- it
shows a few weird chars (a query to the terminal) (until next time that
part of the screen is redrawn ?).

I now see three approaches :
0. Do nothing, and let users fix their terminal emulator and/or terminfo
   entries. (alternatively : provide guidance for doing this.)
1. Like it is done now for rxvt (in function terminal-init-xterm), add
   some ad-hoc code for detecting gnome-terminal which pretends to be
   xterm (in fact the exact same approach might work : $COLORTERM is
   gnome-terminal when using gnome-terminal).
2. Test also (match-string 1 str) in the above code and make sure it is
   either 0 or 41. (it is equal to 1 in my gnome-terminal)

Opinions ?

-- 
Nico.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16988; Package emacs. (Wed, 12 Mar 2014 14:33:02 GMT) Full text and rfc822 format available.

Message #17 received at 16988 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: W. Trevor King <wking <at> tremily.us>
Cc: 16988 <at> debbugs.gnu.org, Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
Subject: xterm--version-handler, accepting any terminal type rather than 0
Date: Wed, 12 Mar 2014 10:32:21 -0400
[Message part 1 (text/plain, inline)]
Hi Trevor,

Looks like my fear about "other terminal types" was not unfounded after
all: gnome-terminal uses a terminal type of 1 and that leads to problems
(see http://debbugs.gnu.org/16988 for the discussion).

I'm leaning towards the conservative option of replacing your "[0-9]+"
with "0\\|41", WDYT?


        Stefan

[Message part 2 (message/rfc822, inline)]
From: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>, 16988 <at> debbugs.gnu.org
Subject: bug#16988: 24.3.50;
	emacs -nw -Q --eval '(kill-emacs)' takes 2 seconds unless I hit a key
Date: Wed, 12 Mar 2014 09:59:13 +0100
Eli Zaretskii <eliz <at> gnu.org> writes:
>> $ time src/emacs -nw -Q --eval '(kill-emacs)'
>> 
>> real	0m2.064s
>> user	0m0.030s
>> sys	0m0.010s

> My crystal ball says that your TERM variable points to xterm, but your
> terminal either isn't xterm or doesn't support the kind of queries
> that xterm--query on xterm.el uses.  That function indeed waits for 2s
> for the terminal to respond. 

Since it was not a problem before, I bisected that down to commit:
commit 7e594297002c7bc07083fa8d01552255e831ba2a
Author: W. Trevor King <wking <at> tremily.us>
Date:   Wed Feb 19 23:45:19 2014 -0500

    * lisp/term/xterm.el (xterm--version-handler): Adapt to xterm-280's output.

which changed xterm--version-handler (in lisp/term/xterm.el) in the following way:

-    (when (string-match "0;\\([0-9]+\\);0" str)
-      (let ((version (string-to-number (match-string 1 str))))
+    ;; Since xterm-280, the terminal type (NUMBER1) is now 41 instead of 0.
+    (when (string-match "\\([0-9]+\\);\\([0-9]+\\);0" str)
+      (let ((version (string-to-number (match-string 2 str))))

That has the effect of now matching gnome-terminal's string (it begins
with 1 on my platform).

As a side effect of this, calling "emacsclient -t" from within
gnome-terminal currently acts weird : it shows the wrong buffer for up
to two second and --if you press some keys before the 2 seconds-- it
shows a few weird chars (a query to the terminal) (until next time that
part of the screen is redrawn ?).

I now see three approaches :
0. Do nothing, and let users fix their terminal emulator and/or terminfo
   entries. (alternatively : provide guidance for doing this.)
1. Like it is done now for rxvt (in function terminal-init-xterm), add
   some ad-hoc code for detecting gnome-terminal which pretends to be
   xterm (in fact the exact same approach might work : $COLORTERM is
   gnome-terminal when using gnome-terminal).
2. Test also (match-string 1 str) in the above code and make sure it is
   either 0 or 41. (it is equal to 1 in my gnome-terminal)

Opinions ?

-- 
Nico.



Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16988; Package emacs. (Wed, 12 Mar 2014 16:14:01 GMT) Full text and rfc822 format available.

Message #20 received at 16988 <at> debbugs.gnu.org (full text, mbox):

From: "W. Trevor King" <wking <at> tremily.us>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 16988 <at> debbugs.gnu.org, Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
Subject: Re: xterm--version-handler, accepting any terminal type rather than 0
Date: Wed, 12 Mar 2014 09:13:24 -0700
[Message part 1 (text/plain, inline)]
On Wed, Mar 12, 2014 at 10:32:21AM -0400, Stefan Monnier wrote:
> Looks like my fear about "other terminal types" was not unfounded
> after all: gnome-terminal uses a terminal type of 1 and that leads
> to problems (see http://debbugs.gnu.org/16988 for the discussion).
> 
> I'm leaning towards the conservative option of replacing your "[0-9]+"
> with "0\\|41", WDYT?

That's going to cause problems for folks who run their XTerm in VT220
mode (xterm -ti vt220), where you'll get secondary device attributes
like '1;297;0c' (VT220, XTerm v297, ROM cartridge registration number
0).  It looks like the GNOME Terminal and it's underlying VTE widget
could use some love on the XTerm-emulation front [1,2].

On Wed, Mar 12, 2014 at 09:59:13AM +0100, Nicolas Richard wrote:
> I now see three approaches :
> 0. Do nothing, and let users fix their terminal emulator and/or
>    terminfo entries. (alternatively : provide guidance for doing
>    this.)
> 1. Like it is done now for rxvt (in function terminal-init-xterm),
>    add some ad-hoc code for detecting gnome-terminal which pretends
>    to be xterm (in fact the exact same approach might work :
>    $COLORTERM is gnome-terminal when using gnome-terminal).
> 2. Test also (match-string 1 str) in the above code and make sure it
>    is either 0 or 41. (it is equal to 1 in my gnome-terminal)

That sounds right to me, and those choices are listed in my order of
preference ;).  VTE's handling of this particular sequence
(vte_sequence_handler_send_secondary_device_attributes) hasn't changed
much since it was added in 2003 [3,4], and I haven't looked up the
sequence behind xterm--query, so I'm not sure how difficult it would
be to add support for it to VTE.  I also don't know enough about it to
know how to reliably distinguish it from true XTerms (although if you
can COLORTERM, that sounds good).  Approach #3 fixes things for VTE
users, but breaks detection for 'xterm -ti vt220' users.  I don't know
any such users personally though ;).

Cheers,
Trevor

[1]: http://invisible-island.net/xterm/xterm.faq.html#bug_gnometerm
[2]: http://invisible-island.net/xterm/xterm.faq.html#vte_widget
[3]: https://git.gnome.org/browse/vte/commit/?id=3c6d81bf06becda3f9ab005c7310b2343588115e
[4]: https://git.gnome.org/browse/vte/commit/?id=ddad9e00e4d0442d761390480aafd9c85713121f

--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[signature.asc (application/pgp-signature, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16988; Package emacs. (Wed, 26 Mar 2014 02:45:02 GMT) Full text and rfc822 format available.

Message #23 received at 16988 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
Cc: 16988 <at> debbugs.gnu.org
Subject: Re: bug#16988: 24.3.50;
 emacs -nw -Q --eval '(kill-emacs)' takes 2 seconds unless I hit a key
Date: Tue, 25 Mar 2014 22:44:18 -0400
> With latest trunk:
> $ time src/emacs -nw -Q --eval '(kill-emacs)'
> real	0m2.064s
> user	0m0.030s
> sys	0m0.010s
> If however I hit a key, emacs exits immediately.

The patch below works for me, but I'm not sure if the terminal type and
version returned by gnome-terminal is "stable" or not.
Can you confirm it fixes your problem as well?


        Stefan


=== modified file 'lisp/term/xterm.el'
--- lisp/term/xterm.el	2014-03-01 18:12:16 +0000
+++ lisp/term/xterm.el	2014-03-26 02:42:05 +0000
@@ -503,6 +503,9 @@
     ;; Since xterm-280, the terminal type (NUMBER1) is now 41 instead of 0.
     (when (string-match "\\([0-9]+\\);\\([0-9]+\\);0" str)
       (let ((version (string-to-number (match-string 2 str))))
+        ;; Hack attack!  bug#16988: gnome-terminal reports "1;3409;0" but is
+        ;; based on a rather old xterm code.
+        (when (equal str "1;3409;0") (setq version 200))
         ;; If version is 242 or higher, assume the xterm supports
         ;; reporting the background color (TODO: maybe earlier
         ;; versions do too...)





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16988; Package emacs. (Wed, 26 Mar 2014 06:48:01 GMT) Full text and rfc822 format available.

Message #26 received at 16988 <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>, 16988 <at> debbugs.gnu.org
Subject: Re: bug#16988: 24.3.50;
 emacs -nw -Q --eval '(kill-emacs)' takes 2 seconds unless I hit a key
Date: Wed, 26 Mar 2014 07:47:18 +0100
Stefan Monnier <monnier <at> IRO.UMontreal.CA> writes:

>> With latest trunk:
>> $ time src/emacs -nw -Q --eval '(kill-emacs)'
>> real	0m2.064s
>> user	0m0.030s
>> sys	0m0.010s
>> If however I hit a key, emacs exits immediately.
>
> The patch below works for me, but I'm not sure if the terminal type and
> version returned by gnome-terminal is "stable" or not.
> Can you confirm it fixes your problem as well?

Apparently, "3409" is not stable :

For what I've tested :
Gnome terminal 3.6.1 reports 1;3406;0
Gnome terminal 2.32.1 reports 1;2802;0

-- 
Nicolas.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16988; Package emacs. (Wed, 26 Mar 2014 10:30:04 GMT) Full text and rfc822 format available.

Message #29 received at 16988 <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 16988 <at> debbugs.gnu.org
Subject: Re: bug#16988: 24.3.50;
 emacs -nw -Q --eval '(kill-emacs)' takes 2 seconds unless I hit a key
Date: Wed, 26 Mar 2014 11:29:11 +0100
Stefan Monnier <monnier <at> IRO.UMontreal.CA> writes:
>> With latest trunk:
>> $ time src/emacs -nw -Q --eval '(kill-emacs)'
>> real	0m2.064s
>> user	0m0.030s
>> sys	0m0.010s
>> If however I hit a key, emacs exits immediately.
>
> The patch below works for me, but I'm not sure if the terminal type and
> version returned by gnome-terminal is "stable" or not.
> Can you confirm it fixes your problem as well?

Here's a patch based on COLORTERM which works for me.

diff --git a/lisp/term/xterm.el b/lisp/term/xterm.el
index eac4014..bd5675b 100644
--- a/lisp/term/xterm.el
+++ b/lisp/term/xterm.el
@@ -503,6 +503,12 @@ The relevant features are:
     ;; Since xterm-280, the terminal type (NUMBER1) is now 41 instead of 0.
     (when (string-match "\\([0-9]+\\);\\([0-9]+\\);0" str)
       (let ((version (string-to-number (match-string 2 str))))
+        ;; gnome-terminal pretends to be xterm but lacks some of its
+        ;; more recent features.  See bug#16988.
+        (let ((colorterm (getenv "COLORTERM" (selected-frame))))
+          (when (and colorterm
+                     (string-match "\\`gnome-terminal" colorterm))
+            (setq version 200)))
         ;; If version is 242 or higher, assume the xterm supports
         ;; reporting the background color (TODO: maybe earlier
         ;; versions do too...)

--
Nico.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16988; Package emacs. (Wed, 26 Mar 2014 12:47:02 GMT) Full text and rfc822 format available.

Message #32 received at 16988 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
Cc: 16988 <at> debbugs.gnu.org
Subject: Re: bug#16988: 24.3.50;
 emacs -nw -Q --eval '(kill-emacs)' takes 2 seconds unless I hit a key
Date: Wed, 26 Mar 2014 08:46:35 -0400
> +        ;; gnome-terminal pretends to be xterm but lacks some of its
> +        ;; more recent features.  See bug#16988.
> +        (let ((colorterm (getenv "COLORTERM" (selected-frame))))
> +          (when (and colorterm
> +                     (string-match "\\`gnome-terminal" colorterm))
> +            (setq version 200)))

As a matter of fact, all my xterms have "COLORTERM = gnome-terminal", so
the above ends up running even though I'm in a plain uptodate xterm
rather than in a gnome-terminal.

This is probably not the usual situation (it's a result of some silly
way I log in), but it does point to the fact that xterm itself does not
reset COLORTERM, so it's not a reliable indicator.


        Stefan




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16988; Package emacs. (Wed, 26 Mar 2014 13:39:02 GMT) Full text and rfc822 format available.

Message #35 received at 16988 <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>, 16988 <at> debbugs.gnu.org
Subject: Re: bug#16988: 24.3.50;
 emacs -nw -Q --eval '(kill-emacs)' takes 2 seconds unless I hit a key
Date: Wed, 26 Mar 2014 14:38:22 +0100
Stefan Monnier <monnier <at> IRO.UMontreal.CA> writes:
>> +        ;; gnome-terminal pretends to be xterm but lacks some of its
>> +        ;; more recent features.  See bug#16988.
>> +        (let ((colorterm (getenv "COLORTERM" (selected-frame))))
>> +          (when (and colorterm
>> +                     (string-match "\\`gnome-terminal" colorterm))
>> +            (setq version 200)))
>
> As a matter of fact, all my xterms have "COLORTERM = gnome-terminal", so
> the above ends up running even though I'm in a plain uptodate xterm
> rather than in a gnome-terminal.
>
> This is probably not the usual situation (it's a result of some silly
> way I log in), but it does point to the fact that xterm itself does not
> reset COLORTERM, so it's not a reliable indicator.

If we have reasons to believe xterm will never reach e.g. version 1500,
perhaps we can test for that.

-- 
Nico.




Reply sent to Stefan Monnier <monnier <at> IRO.UMontreal.CA>:
You have taken responsibility. (Tue, 22 Apr 2014 20:37:01 GMT) Full text and rfc822 format available.

Notification sent to Nicolas Richard <theonewiththeevillook <at> yahoo.fr>:
bug acknowledged by developer. (Tue, 22 Apr 2014 20:37:03 GMT) Full text and rfc822 format available.

Message #40 received at 16988-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
Cc: 16988-done <at> debbugs.gnu.org
Subject: Re: bug#16988: 24.3.50;
 emacs -nw -Q --eval '(kill-emacs)' takes 2 seconds unless I hit a key
Date: Tue, 22 Apr 2014 16:36:15 -0400
> If we have reasons to believe xterm will never reach e.g. version 1500,
> perhaps we can test for that.

I installed a patch along those lines, using 2000 as the "threshold".


        Stefan




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Wed, 21 May 2014 11:24:04 GMT) Full text and rfc822 format available.

This bug report was last modified 9 years and 314 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.