GNU bug report logs -
#10427
coreutils-8.14.116-1e18d: testsuite failures on NetBSD 5.1
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 10427 in the body.
You can then email your comments to 10427 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-coreutils <at> gnu.org
:
bug#10427
; Package
coreutils
.
(Tue, 03 Jan 2012 17:37:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Stefano Lattarini <stefano.lattarini <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-coreutils <at> gnu.org
.
(Tue, 03 Jan 2012 17:37:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Jim.
On 01/03/2012 06:10 PM, Jim Meyering wrote:
> FYI, here's a snapshot of what will soon be coreutils-8.15,
> expected on Thursday or Friday.
>
> coreutils snapshot:
> http://meyering.net/cu/coreutils-ss.tar.xz 5.2 MB
> http://meyering.net/cu/coreutils-ss.tar.xz.sig
> http://meyering.net/cu/coreutils-8.14.116-1e18d.tar.xz
>
Minimal system info:
$ uname -n -s -r
NetBSD gcc70.fsffrance.org 5.1
Commands used to test the snapshot package:
$ (set -x \
> && ./configure \
> && cat config.log \
> && make -j4 all \
> && VERBOSE=yes AM_COLOR_TESTS=always make -j4 check \
> ) 2>&1 | tee all.log
...
=================================================================
Testsuite summary for GNU coreutils 8.14.116-1e18d
=================================================================
# TOTAL: 466
# PASS: 366
# SKIP: 86
# XFAIL: 0
# FAIL: 14
# XPASS: 0
# ERROR: 0
==================================================================
...
make: stopped in /home/slattarini/tmp/coreutils-8.14.116-1e18d
*** [check] Error code 2
1 error
(BTW, I see you have used bleeding-edge automake from master to build
the snapshot; are you sure that is safe for production code? Because
I'm not ...)
Attached are the (compressed) contents of the all.log file. Let me know
if you need more information.
Regards,
Stefano
[all.log.xz (application/octet-stream, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#10427
; Package
coreutils
.
(Thu, 05 Jan 2012 09:05:02 GMT)
Full text and
rfc822 format available.
Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):
I'm sending this to bug-automake because I think it's an automake
issue. However, the problem causes the latest coreutils snapshot
to fail to build, so I'm CC'ing to bug-coreutils.
> On 01/03/2012 06:10 PM, Jim Meyering wrote:
>> FYI, here's a snapshot of what will soon be coreutils-8.15,
>> expected on Thursday or Friday.
>>
>> coreutils snapshot:
>> http://meyering.net/cu/coreutils-ss.tar.xz 5.2 MB
>> http://meyering.net/cu/coreutils-ss.tar.xz.sig
>> http://meyering.net/cu/coreutils-8.14.116-1e18d.tar.xz
This snapshot doesn't build on Solaris 8 (sparc) with native tools,
for a couple of reasons. I don't expect Solaris 8 is an active
porting target any more, but these problems could well happen on
active targets.
First, there's code like this in tests/Makefile.in:
$(am__common_driver_flags) $(AM_LOG_DRIVER_FLAGS) $(LOG_DRIVER_FLAGS) -- $(LOG_COMPILE) "$$tst" \
$(AM_TESTS_FD_REDIRECT)
This code is generated by Automake. Here, AM_TESTS_FD_REDIRECT
is empty. Solaris 8 'make' executes the above as follows:
bash -c '[expansion of previous line] \'
and Bash complains about a syntax error with the trailing backslash.
How about changing Automake to generate something like this instead,
with no backslash-newline?
$(am__common_driver_flags) $(AM_LOG_DRIVER_FLAGS) $(LOG_DRIVER_FLAGS) -- $(LOG_COMPILE) "$$tst" $(AM_TESTS_FD_REDIRECT)
This should avoid the problem.
Second, there's code like this in tests/Makefile.in:
@list='$(TEST_LOGS)'; \
list=`for i in $$list; do \
test .log = $$i || echo $$i; \
done | tr '\012\015' ' '`; \
list=`echo "$$list" | sed 's/ *$$//'`; \
This generates a long line and sends it to 'sed',
which complains "Output line too long." and outputs nothing.
This code is also generated by Automake. How about changing Automake
to generate something like this instead?
@test_logs='$(TEST_LOGS)'; \
list=; \
for i in $$test_logs; do \
test .log = "$$i" || list="$$list $$i"; \
done; \
This avoids the business with echo and tr and ` sed and
avoids the sed limitation with long lines.
Automake does this latter sort of thing in about 4 places,
and I figure it's done that way for a reason, but I don't
know what the reason is.
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#10427
; Package
coreutils
.
(Thu, 05 Jan 2012 09:05:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#10427
; Package
coreutils
.
(Thu, 05 Jan 2012 12:52:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 10427 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
[adding bug-automake in CC:]
Reference: <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10427#8>
Hi Paul, thanks for the report and diagnosis.
On 01/05/2012 10:00 AM, Paul Eggert wrote:
> I'm sending this to bug-automake because I think it's an automake
> issue. However, the problem causes the latest coreutils snapshot
> to fail to build, so I'm CC'ing to bug-coreutils.
>
>> On 01/03/2012 06:10 PM, Jim Meyering wrote:
>>> FYI, here's a snapshot of what will soon be coreutils-8.15,
>>> expected on Thursday or Friday.
>>>
>>> coreutils snapshot:
>>> http://meyering.net/cu/coreutils-ss.tar.xz 5.2 MB
>>> http://meyering.net/cu/coreutils-ss.tar.xz.sig
>>> http://meyering.net/cu/coreutils-8.14.116-1e18d.tar.xz
>
> This snapshot doesn't build on Solaris 8 (sparc) with native tools,
> for a couple of reasons. I don't expect Solaris 8 is an active
> porting target any more, but these problems could well happen on
> active targets.
>
I agree that this issues might prove a liability on some modern systems
too, and that we should fix them. (BTW, if you feel like running the
whole automake testsuite on Solaris 8 to find more similar issues, I
wouldn't object ;-)
> First, there's code like this in tests/Makefile.in:
>
> $(am__common_driver_flags) $(AM_LOG_DRIVER_FLAGS) $(LOG_DRIVER_FLAGS) -- $(LOG_COMPILE) "$$tst" \
> $(AM_TESTS_FD_REDIRECT)
>
> This code is generated by Automake. Here, AM_TESTS_FD_REDIRECT
> is empty. Solaris 8 'make' executes the above as follows:
>
> bash -c '[expansion of previous line] \'
>
> and Bash complains about a syntax error with the trailing backslash.
>
I can reproduce this with bash 2.05b on Debian.
Attached is a fix for this bug, with a testcase. The test is quite
elaborate and somewhat hacky, but I'd rather keep it anyway, since
I'm planning to refactor it into an external helper script that will
be used to guard against other unwanted trailing `\' in *all* the
make recipes run in the automake testsuite (that's for a follow-up
patch obviously).
> How about changing Automake to generate something like this instead,
> with no backslash-newline?
>
> $(am__common_driver_flags) $(AM_LOG_DRIVER_FLAGS) $(LOG_DRIVER_FLAGS) -- $(LOG_COMPILE) "$$tst" $(AM_TESTS_FD_REDIRECT)
>
> This should avoid the problem.
>
I ended up breaking the line in a "safer" place instead. It is enough
to fix the bug.
Regards,
Stefano
[0001-parallel-tests-avoid-trailing-backslashes-in-make-re.patch (text/x-diff, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#10427
; Package
coreutils
.
(Thu, 05 Jan 2012 13:13:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 10427 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 01/05/2012 01:47 PM, Stefano Lattarini wrote:
> [adding bug-automake in CC:]
>
> Reference: <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=104367#8>
>
And here is the definitive version of the patch that I'll push by this
evening (to master) if there is no objection.
Thanks,
Stefano
[0001-parallel-tests-avoid-trailing-backslashes-in-make-re.patch (text/x-diff, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#10427
; Package
coreutils
.
(Thu, 05 Jan 2012 14:11:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 10427 <at> debbugs.gnu.org (full text, mbox):
[adding bug-automake in CC:]
Reference: <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10427#8>
Hi Paul, thanks for the report and diagnosis.
On 01/05/2012 10:00 AM, Paul Eggert wrote:
> The latest coreutils snapshot fail to build
>
>> On 01/03/2012 06:10 PM, Jim Meyering wrote:
>>> FYI, here's a snapshot of what will soon be coreutils-8.15,
>>> expected on Thursday or Friday.
>>>
>>> coreutils snapshot:
>>> http://meyering.net/cu/coreutils-ss.tar.xz 5.2 MB
>>> http://meyering.net/cu/coreutils-ss.tar.xz.sig
>>> http://meyering.net/cu/coreutils-8.14.116-1e18d.tar.xz
>
> This snapshot doesn't build on Solaris 8 (sparc) with native tools,
> for a couple of reasons. I don't expect Solaris 8 is an active
> porting target any more, but these problems could well happen on
> active targets.
>
I agree.
> Second, there's code like this in tests/Makefile.in:
>
> @list='$(TEST_LOGS)'; \
> list=`for i in $$list; do \
> test .log = $$i || echo $$i; \
> done | tr '\012\015' ' '`; \
> list=`echo "$$list" | sed 's/ *$$//'`; \
>
> This generates a long line and sends it to 'sed',
> which complains "Output line too long." and outputs nothing.
>
And if I'm not mistaken, sed is allowed such a behaviour by POSIX, so this
is a portability problem in automake.
> This code is also generated by Automake. How about changing Automake
> to generate something like this instead?
>
> @test_logs='$(TEST_LOGS)'; \
> list=; \
> for i in $$test_logs; do \
> test .log = "$$i" || list="$$list $$i"; \
> done; \
>
> This avoids the business with echo and tr and ` sed and
> avoids the sed limitation with long lines.
>
Good idea. I will followed your idea (with some tweaks).
Patch coming up soon.
> Automake does this latter sort of thing in about 4 places,
>
Which "sort of thing" exactly? I could find only one place which suffers
of the problem you've pointed out, i.e., the `recheck recheck-html' rules
in lib/am/check.am. Am I missing something?
> and I figure it's done that way for a reason, but I don't
> know what the reason is.
>
The comments in lib/am/check.am should be explicative enough. if not,
that's a (minor) bug, so feel free to report it!
Thanks,
Stefano
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#10427
; Package
coreutils
.
(Thu, 05 Jan 2012 14:48:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 10427 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Reference:
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10437>
On 01/05/2012 03:07 PM, Stefano Lattarini wrote:
>
> Patch coming up soon.
>
And here it is. I will push by this evening if there is no objection.
Regards,
Stefano
[0001-parallel-tests-avoid-issue-with-overly-long-lines-in.patch (text/x-diff, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#10427
; Package
coreutils
.
(Thu, 05 Jan 2012 18:11:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 10427 <at> debbugs.gnu.org (full text, mbox):
On 01/05/12 06:07, Stefano Lattarini wrote:
> Which "sort of thing" exactly? I could find only one place which suffers
> of the problem you've pointed out, i.e., the `recheck recheck-html' rules
> in lib/am/check.am. Am I missing something?
Sorry, that appears to have been a miscount on my part:
I was counting some files that Automake generates for itself
while building. In Automake source there are only two instances,
which your patch caught: the 'recheck recheck-html' rule and
the 'check-TESTS' rule (the latter is what actually triggered
the problem with coreutils). So this should be OK.
Thanks for the quick fixes, by the way!
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#10427
; Package
coreutils
.
(Thu, 05 Jan 2012 18:29:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 10427 <at> debbugs.gnu.org (full text, mbox):
On 01/05/2012 07:06 PM, Paul Eggert wrote:
> On 01/05/12 06:07, Stefano Lattarini wrote:
>> Which "sort of thing" exactly? I could find only one place which suffers
>> of the problem you've pointed out, i.e., the `recheck recheck-html' rules
>> in lib/am/check.am. Am I missing something?
>
> Sorry, that appears to have been a miscount on my part:
> I was counting some files that Automake generates for itself
> while building. In Automake source there are only two instances,
> which your patch caught: the 'recheck recheck-html' rule and
> the 'check-TESTS' rule (the latter is what actually triggered
> the problem with coreutils).
>
Wait, the `check-TESTS' rules didn't use any sed invocation, so it wouldn't make
sense for it to trip for a sed failure ... What am I missing?
Thanks,
Stefano
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#10427
; Package
coreutils
.
(Thu, 05 Jan 2012 18:43:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 10427 <at> debbugs.gnu.org (full text, mbox):
On 01/05/2012 07:24 PM, Stefano Lattarini wrote:
> On 01/05/2012 07:06 PM, Paul Eggert wrote:
>> On 01/05/12 06:07, Stefano Lattarini wrote:
>>> Which "sort of thing" exactly? I could find only one place which suffers
>>> of the problem you've pointed out, i.e., the `recheck recheck-html' rules
>>> in lib/am/check.am. Am I missing something?
>>
>> Sorry, that appears to have been a miscount on my part:
>> I was counting some files that Automake generates for itself
>> while building. In Automake source there are only two instances,
>> which your patch caught: the 'recheck recheck-html' rule and
>> the 'check-TESTS' rule (the latter is what actually triggered
>> the problem with coreutils).
>>
> Wait, the `check-TESTS' rules didn't use any sed invocation, so it wouldn't make
> sense for it to trip for a sed failure ... What am I missing?
>
I will answer myself: I was missing the fact that such a sed invocation had
been added to check-TESTS, *but in master only*. Anyway, the maint -> master
merge will take care of everything.
Thanks, and sorry for the noise,
Stefano
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#10427
; Package
coreutils
.
(Thu, 05 Jan 2012 20:44:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 10427 <at> debbugs.gnu.org (full text, mbox):
I pushed the following doc fix into Autoconf, so that these two portability
issues are documented there. It turns out that the second issue
is actually due to an old Bash bug -- it's not Solaris-specific.
From b1f0e147aa7aa259dea2c34c5a0ac7965d6efd7e Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert <at> cs.ucla.edu>
Date: Thu, 5 Jan 2012 11:00:45 -0800
Subject: [PATCH 1/2] doc: clarify sed buffer limit
* doc/autoconf.texi (Limitations of Usual Tools):
That 4000-byte limit applies to output and internal buffers, too.
---
ChangeLog | 6 ++++++
doc/autoconf.texi | 5 +++--
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 30312be..238c09f 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2012-01-05 Paul Eggert <eggert <at> cs.ucla.edu>
+
+ doc: clarify sed buffer limit
+ * doc/autoconf.texi (Limitations of Usual Tools):
+ That 4000-byte limit applies to output and internal buffers, too.
+
2012-01-03 Paul Eggert <eggert <at> cs.ucla.edu>
maint: update copyright year
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 72ff7f8..ea2419b 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -19256,8 +19256,9 @@ $ @kbd{echo a | sed 's/x/x/;;s/x/x/'}
sed: 1: "s/x/x/;;s/x/x/": invalid command code ;
@end example
-Input should not have unreasonably long lines, since some @command{sed}
-implementations have an input buffer limited to 4000 bytes. Likewise,
+Some @command{sed} implementations have a buffer limited to 4000 bytes,
+and this limits the size of input lines, output lines, and internal
+buffers that can be processed portably. Likewise,
not all @command{sed} implementations can handle embedded @code{NUL} or
a missing trailing newline.
--
1.7.6.5
From 0445b4ad121e6356f409833dec3678ae613e1d08 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert <at> cs.ucla.edu>
Date: Thu, 5 Jan 2012 12:32:12 -0800
Subject: [PATCH 2/2] doc: mention Bash 2.03 bug with backslash-newline
* doc/autoconf.texi (Invoking the Shell): New section.
(Backslash-Newline-Empty): Rename from Backslash-Newline-Newline.
Mention problem with Bash 2.03.
---
ChangeLog | 5 ++++
doc/autoconf.texi | 56 +++++++++++++++++++++++++++++++++++++++++++++++++---
2 files changed, 57 insertions(+), 4 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 238c09f..69df405 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,10 @@
2012-01-05 Paul Eggert <eggert <at> cs.ucla.edu>
+ doc: mention Bash 2.03 bug with backslash-newline
+ * doc/autoconf.texi (Invoking the Shell): New section.
+ (Backslash-Newline-Empty): Rename from Backslash-Newline-Newline.
+ Mention problem with Bash 2.03.
+
doc: clarify sed buffer limit
* doc/autoconf.texi (Limitations of Usual Tools):
That 4000-byte limit applies to output and internal buffers, too.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index ea2419b..5c3feef 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -501,6 +501,7 @@ Dependencies Between Macros
Portable Shell Programming
* Shellology:: A zoology of shells
+* Invoking the Shell:: Invoking the shell as a command
* Here-Documents:: Quirks and tricks
* File Descriptors:: FDs and redirections
* Signal Handling:: Shells, signals, and headaches
@@ -520,7 +521,7 @@ Portable Make Programming
* $< in Ordinary Make Rules:: $< in ordinary rules
* Failure in Make Rules:: Failing portably in rules
* Special Chars in Names:: Special Characters in Macro Names
-* Backslash-Newline-Newline:: Empty last lines in macro definitions
+* Backslash-Newline-Empty:: Empty lines after backslash-newline
* Backslash-Newline Comments:: Spanning comments across line boundaries
* Long Lines in Makefiles:: Line length limitations
* Macros and Submakes:: @code{make macro=value} and submakes
@@ -15067,6 +15068,7 @@ subset described above, is fairly portable nowadays. Also please see
@menu
* Shellology:: A zoology of shells
+* Invoking the Shell:: Invoking the shell as a command
* Here-Documents:: Quirks and tricks
* File Descriptors:: FDs and redirections
* Signal Handling:: Shells, signals, and headaches
@@ -15205,6 +15207,28 @@ The default Mac OS X @command{sh} was originally Zsh; it was changed to
Bash in Mac OS X 10.2.
@end table
+@node Invoking the Shell
+@section Invoking the Shell
+@cindex invoking the shell
+@cindex shell invocation
+
+Bash 2.03 has a bug when invoked with the @option{-c} option: if the
+option-argument ends in backslash-newline, Bash incorrectly reports a
+syntax error. The problem does not occur if a character follows the
+backslash:
+
+@example
+$ @kbd{$ bash -c 'echo foo \}
+> @kbd{'}
+bash: -c: line 2: syntax error: unexpected end of file
+$ @kbd{bash -c 'echo foo \}
+> @kbd{ '}
+foo
+@end example
+
+@noindent
+@xref{Backslash-Newline-Empty}, for how this can cause problems in makefiles.
+
@node Here-Documents
@section Here-Documents
@cindex Here-documents
@@ -19663,7 +19687,7 @@ itself.
* $< in Ordinary Make Rules:: $< in ordinary rules
* Failure in Make Rules:: Failing portably in rules
* Special Chars in Names:: Special Characters in Macro Names
-* Backslash-Newline-Newline:: Empty last lines in macro definitions
+* Backslash-Newline-Empty:: Empty lines after backslash-newline
* Backslash-Newline Comments:: Spanning comments across line boundaries
* Long Lines in Makefiles:: Line length limitations
* Macros and Submakes:: @code{make macro=value} and submakes
@@ -19741,8 +19765,32 @@ this is test
@noindent
However, this problem is no longer of practical concern.
-@node Backslash-Newline-Newline
-@section Backslash-Newline-Newline in Make Macro Values
+@node Backslash-Newline-Empty
+@section Backslash-Newline Before Empty Lines
+
+A bug in Bash 2.03 can cause problems if a Make rule contains a
+backslash-newline followed by line that expands to nothing.
+For example, on Solaris 8:
+
+@example
+SHELL = /bin/bash
+EMPTY =
+foo:
+ touch foo \
+ $(EMPTY)
+@end example
+
+@noindent
+executes
+
+@example
+/bin/bash -c 'touch foo \
+'
+@end example
+
+@noindent
+which fails with a syntax error, due to the Bash bug. To avoid this
+problem, avoid nullable macros in the last line of a multiline command.
@c This has been seen on ia64 hpux 11.20, and on one hppa hpux 10.20,
@c but another hppa hpux 10.20 didn't have it. Bob Proulx
--
1.7.6.5
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#10427
; Package
coreutils
.
(Fri, 06 Jan 2012 10:02:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 10427 <at> debbugs.gnu.org (full text, mbox):
On 01/05/2012 02:08 PM, Stefano Lattarini wrote:
> On 01/05/2012 01:47 PM, Stefano Lattarini wrote:
>> [adding bug-automake in CC:]
>>
>> Reference: <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=104367#8>
>>
> And here is the definitive version of the patch that I'll push by this
> evening (to master) if there is no objection.
>
Pushed now.
Regards,
Stefano
Added tag(s) fixed.
Request was from
Assaf Gordon <assafgordon <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Mon, 15 Oct 2018 15:21:02 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
10427 <at> debbugs.gnu.org and Stefano Lattarini <stefano.lattarini <at> gmail.com>
Request was from
Assaf Gordon <assafgordon <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Mon, 15 Oct 2018 15:21:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Tue, 13 Nov 2018 12:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 6 years and 313 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.