GNU bug report logs -
#32304
27.0.50; tramp-tests issue with double slash
Previous Next
Reported by: Ken Brown <kbrown <at> cornell.edu>
Date: Sun, 29 Jul 2018 15:55:01 UTC
Severity: normal
Found in version 27.0.50
Fixed in version 27.1
Done: Michael Albinus <michael.albinus <at> gmx.de>
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 32304 in the body.
You can then email your comments to 32304 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32304
; Package
emacs
.
(Sun, 29 Jul 2018 15:55:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Ken Brown <kbrown <at> cornell.edu>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Sun, 29 Jul 2018 15:55: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)]
The following parts of tramp-test04-substitute-in-file-name are failing
on Cygwin (and probably also on MS-Windows, but I can't easily test
that):
(should
(string-equal
(substitute-in-file-name "/method:host://foo") "/method:host:/foo"))
(should
(string-equal (substitute-in-file-name "/method:host:/path///foo")
"/foo"))
(should
(string-equal (substitute-in-file-name "/method:host://~foo") "/~foo"))
Here are the corresponding evaluations:
(substitute-in-file-name "/method:host://foo")
"/method:host://foo"
(substitute-in-file-name "/method:host:/path///foo")
"//foo"
(substitute-in-file-name "/method:host://~foo")
"//~foo"
This is a consequence of the fact that Tramp calls
substitute-in-file-name on the local part of the file name:
(substitute-in-file-name "//foo")
"//foo"
(substitute-in-file-name "/path///foo")
"//foo"
(substitute-in-file-name "//~foo")
"//~foo"
"//" has a special meaning at the beginning of a file name on Cygwin and
MS-Windows; see the comment near the beginning of
search_embedded_absfilename. So I don't think there's a real bug here.
Maybe the expected result of the test should simply be adjusted, as in
the attached patch. Someone who builds on MS-Windows would have to
check this.
Ken
[0001-Adjust-expected-results-on-a-tramp-test.patch (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32304
; Package
emacs
.
(Sun, 29 Jul 2018 16:28:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 32304 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Ken Brown <kbrown <at> cornell.edu> writes:
Hi Ken,
> "//" has a special meaning at the beginning of a file name on Cygwin and
> MS-Windows; see the comment near the beginning of
> search_embedded_absfilename. So I don't think there's a real bug here.
> Maybe the expected result of the test should simply be adjusted, as in
> the attached patch. Someone who builds on MS-Windows would have to
> check this.
Thanks for the report. However, your patch seems just to hide the
problem in tramp-tests.el. Wouldn't it be better to fix this?
What about the appended patch?
> Ken
Best regards, Michael.
[Message part 2 (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32304
; Package
emacs
.
(Sun, 29 Jul 2018 16:48:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 32304 <at> debbugs.gnu.org (full text, mbox):
On 7/29/2018 12:27 PM, Michael Albinus wrote:
Hi Michael,
> Thanks for the report. However, your patch seems just to hide the
> problem in tramp-tests.el. Wouldn't it be better to fix this?
Yes, absolutely.
> What about the appended patch?
I think something further must be needed. The test still fails in the
same way.
Best regards,
Ken
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32304
; Package
emacs
.
(Sun, 29 Jul 2018 16:56:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 32304 <at> debbugs.gnu.org (full text, mbox):
Ken Brown <kbrown <at> cornell.edu> writes:
> Hi Michael,
Hi Ken,
>> What about the appended patch?
>
> I think something further must be needed. The test still fails in the
> same way.
OK, needs an MS Windows machine for test. Will do when possible;
officially, I'm on vacation this week. (Don't tell my wife my presence
in emacs-devel :-)
> Best regards,
>
> Ken
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32304
; Package
emacs
.
(Sun, 29 Jul 2018 17:02:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 32304 <at> debbugs.gnu.org (full text, mbox):
On 7/29/2018 12:55 PM, Michael Albinus wrote:
> OK, needs an MS Windows machine for test. Will do when possible;
> officially, I'm on vacation this week. (Don't tell my wife my presence
> in emacs-devel :-)
Your secret is safe with me. Enjoy your vacation.
Ken
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32304
; Package
emacs
.
(Sun, 29 Jul 2018 17:27:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 32304 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Date: Sun, 29 Jul 2018 18:27:40 +0200
> Cc: 32304 <at> debbugs.gnu.org
>
> > "//" has a special meaning at the beginning of a file name on Cygwin and
> > MS-Windows; see the comment near the beginning of
> > search_embedded_absfilename. So I don't think there's a real bug here.
> > Maybe the expected result of the test should simply be adjusted, as in
> > the attached patch. Someone who builds on MS-Windows would have to
> > check this.
>
> Thanks for the report. However, your patch seems just to hide the
> problem in tramp-tests.el. Wouldn't it be better to fix this?
>
> What about the appended patch?
Doesn't seem to help here, in the native MS-Windows build; log
attached.
Can you tell how binding system-type was supposed to solve this?
[tramp-tests.log (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32304
; Package
emacs
.
(Mon, 30 Jul 2018 08:27:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 32304 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
Hi Eli,
> Can you tell how binding system-type was supposed to solve this?
Some functions behave differently depending the system type Emacs is
running on. See for example `shell-quote-argument':
(shell-quote-argument "String with quotation mark \"")
=> "String\\ with\\ quotation\\ mark\\ \\\"" on `gnu/linux'.
=> "^\"String with quotation mark \\^\"^\"" on `windows-nt'
Often, Tramp needs the non-windows kind of result for the remote
host. So it is a common technique in Tramp to force this with
"(let ((system-type 'not-windows)) ...)".
Unfortunately, it doesn't work with `substitute-in-file-name'. I will
look for another solution.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32304
; Package
emacs
.
(Mon, 30 Jul 2018 10:44:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 32304 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Ken Brown <kbrown <at> cornell.edu> writes:
> Hi Michael,
Hi Ken,
> I think something further must be needed. The test still fails in the
> same way.
There's another patch, could you pls check?
> Best regards,
>
> Ken
Best regards, Michael.
[Message part 2 (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32304
; Package
emacs
.
(Mon, 30 Jul 2018 12:18:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 32304 <at> debbugs.gnu.org (full text, mbox):
On 7/30/2018 6:43 AM, Michael Albinus wrote:
Hi Michael,
> There's another patch, could you pls check?
Yes, that fixes it on Cygwin. Thanks.
Best regards,
Ken
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32304
; Package
emacs
.
(Mon, 30 Jul 2018 14:46:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 32304 <at> debbugs.gnu.org (full text, mbox):
> From: Ken Brown <kbrown <at> cornell.edu>
> Date: Mon, 30 Jul 2018 08:17:48 -0400
> Cc: 32304 <at> debbugs.gnu.org
>
> On 7/30/2018 6:43 AM, Michael Albinus wrote:
>
> Hi Michael,
>
> > There's another patch, could you pls check?
>
> Yes, that fixes it on Cygwin. Thanks.
The MinGW build also passes, but the other two still fail:
2 unexpected results:
FAILED tramp-test43-auto-load
FAILED tramp-test44-unload
Should they be skipped?
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32304
; Package
emacs
.
(Mon, 30 Jul 2018 20:51:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 32304 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
Hi Eli,
> The MinGW build also passes, but the other two still fail:
>
> 2 unexpected results:
> FAILED tramp-test43-auto-load
> FAILED tramp-test44-unload
>
> Should they be skipped?
I would like to see the ERT error messages.
> Thanks.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32304
; Package
emacs
.
(Tue, 31 Jul 2018 02:35:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 32304 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: Ken Brown <kbrown <at> cornell.edu>, 32304 <at> debbugs.gnu.org
> Date: Mon, 30 Jul 2018 22:50:39 +0200
>
> > The MinGW build also passes, but the other two still fail:
> >
> > 2 unexpected results:
> > FAILED tramp-test43-auto-load
> > FAILED tramp-test44-unload
> >
> > Should they be skipped?
>
> I would like to see the ERT error messages.
The full log is attached.
[tramp-tests.log (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32304
; Package
emacs
.
(Tue, 31 Jul 2018 04:59:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 32304 <at> debbugs.gnu.org (full text, mbox):
Ken Brown <kbrown <at> cornell.edu> writes:
> Hi Michael,
Hi Ken,
>> There's another patch, could you pls check?
>
> Yes, that fixes it on Cygwin. Thanks.
Thanks for testing (also to Eli)! I've committed the patch to master.
> Best regards,
>
> Ken
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32304
; Package
emacs
.
(Tue, 31 Jul 2018 05:01:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 32304 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> > The MinGW build also passes, but the other two still fail:
>> >
>> > 2 unexpected results:
>> > FAILED tramp-test43-auto-load
>> > FAILED tramp-test44-unload
>> >
>> > Should they be skipped?
>>
>> I would like to see the ERT error messages.
>
> The full log is attached.
Thanks. I will work on it when I have access to an MS Windows machine;
likely next week.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32304
; Package
emacs
.
(Tue, 31 Jul 2018 14:47:01 GMT)
Full text and
rfc822 format available.
Message #47 received at submit <at> debbugs.gnu.org (full text, mbox):
On Sun 29 Jul 2018, Michael Albinus wrote:
> Ken Brown <kbrown <at> cornell.edu> writes:
>
> Hi Ken,
>
>> "//" has a special meaning at the beginning of a file name on Cygwin and
>> MS-Windows; see the comment near the beginning of
>> search_embedded_absfilename. So I don't think there's a real bug here.
POSIX specifies that "//" is handled in an implementation defined
manner, so Cygwin and Windows are not really special.
See POSIX section 4.13 Pathname Resolution:
A pathname consisting of a single <slash> shall resolve to the root
directory of the process. A null pathname shall not be successfully
resolved. If a pathname begins with two successive <slash> characters,
the first component following the leading <slash> characters may be
interpreted in an implementation-defined manner, although more than two
leading <slash> characters shall be treated as a single <slash>
character.
<http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_13>
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32304
; Package
emacs
.
(Tue, 31 Jul 2018 20:59:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 32304 <at> debbugs.gnu.org (full text, mbox):
Andy Moreton <andrewjmoreton <at> gmail.com> writes:
Hi Andy,
> POSIX specifies that "//" is handled in an implementation defined
> manner, so Cygwin and Windows are not really special.
>
> See POSIX section 4.13 Pathname Resolution:
>
> A pathname consisting of a single <slash> shall resolve to the root
> directory of the process. A null pathname shall not be successfully
> resolved. If a pathname begins with two successive <slash> characters,
> the first component following the leading <slash> characters may be
> interpreted in an implementation-defined manner, although more than two
> leading <slash> characters shall be treated as a single <slash>
> character.
But the Emacs implementation handles only Cygwin and MS Windows as
special. This is POSIX conform, because it declares this as
implementation specific.
The question is, whether Tramp should follow this. It does
(substitute-in-file-name "/ssh::/a///b") => "/b"
Maybe, it shall return on Cygwin and MS-Windows
(substitute-in-file-name "/ssh::/a///b") => "//b"
Don't know. Is this too sophisticated?
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32304
; Package
emacs
.
(Tue, 31 Jul 2018 22:08:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 32304 <at> debbugs.gnu.org (full text, mbox):
On 7/31/2018 4:57 PM, Michael Albinus wrote:
> The question is, whether Tramp should follow this. It does
>
> (substitute-in-file-name "/ssh::/a///b") => "/b"
This seems right to me. After all, the repeated slash is not at the
beginning of the (total) file name.
> Maybe, it shall return on Cygwin and MS-Windows
>
> (substitute-in-file-name "/ssh::/a///b") => "//b"
I can't think of any situation where this would be useful.
Ken
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32304
; Package
emacs
.
(Wed, 01 Aug 2018 20:53:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 32304 <at> debbugs.gnu.org (full text, mbox):
Ken Brown <kbrown <at> cornell.edu> writes:
> I can't think of any situation where this would be useful.
OK, I don't do anything.
> Ken
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32304
; Package
emacs
.
(Wed, 08 Aug 2018 13:49:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 32304 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
Hi Eli,
>> > 2 unexpected results:
>> > FAILED tramp-test43-auto-load
>> > FAILED tramp-test44-unload
>> >
>> > Should they be skipped?
I cannot find any MS Windows build of Emacs 27. So I have used the
Cygwin Emacs 27.0.50 I've got recently from Ken.
> The full log is attached.
>
> Test tramp-test43-auto-load condition:
> (ert-test-failed
> ((should
> (string-match "Tramp loaded: t[
> ]+"
> (shell-command-to-string ...)))
> :form
> (string-match "Tramp loaded: t[
> ]+" "Tramp loaded: nil
> ")
> :value nil))
> FAILED 59/63 tramp-test43-auto-load (0.203125 sec)
This error didn't happen with the Cygnus Emacs :-(
> Test tramp-test44-unload condition:
> (ert-test-failed "`tramp-register-archive-file-name-handler' still bound")
> FAILED 63/63 tramp-test44-unload (0.359375 sec)
Cygnus Emacs has reported also an error for this test, but with a
different message. I have fixed this and committed to master, maybe it
is fixed for you as well.
Anyway, for further investigations I'll need an Emacs 27 for MS
Windows. Do you know where I could get a recent one? I have found only
Emacs 26.1 for MS Windows.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32304
; Package
emacs
.
(Wed, 08 Aug 2018 14:36:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 32304 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: kbrown <at> cornell.edu, 32304 <at> debbugs.gnu.org
> Date: Wed, 08 Aug 2018 15:48:07 +0200
>
> Cygnus Emacs has reported also an error for this test, but with a
> different message. I have fixed this and committed to master, maybe it
> is fixed for you as well.
Thanks, will do.
> Anyway, for further investigations I'll need an Emacs 27 for MS
> Windows. Do you know where I could get a recent one?
How recent must "recent" be? The last snapshot here:
https://alpha.gnu.org/gnu/emacs/pretest/windows/emacs-27/
is from May 4.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32304
; Package
emacs
.
(Wed, 08 Aug 2018 14:43:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 32304 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> Date: Wed, 08 Aug 2018 17:35:22 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 32304 <at> debbugs.gnu.org
>
> > From: Michael Albinus <michael.albinus <at> gmx.de>
> > Cc: kbrown <at> cornell.edu, 32304 <at> debbugs.gnu.org
> > Date: Wed, 08 Aug 2018 15:48:07 +0200
> >
> > Cygnus Emacs has reported also an error for this test, but with a
> > different message. I have fixed this and committed to master, maybe it
> > is fixed for you as well.
>
> Thanks, will do.
It still fails, I attach the full log below.
Thanks.
[tramp-tests.log (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32304
; Package
emacs
.
(Wed, 08 Aug 2018 15:27:01 GMT)
Full text and
rfc822 format available.
Message #68 received at 32304 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Anyway, for further investigations I'll need an Emacs 27 for MS
>> Windows. Do you know where I could get a recent one?
>
> How recent must "recent" be? The last snapshot here:
>
> https://alpha.gnu.org/gnu/emacs/pretest/windows/emacs-27/
>
> is from May 4.
I could swear I've checked there, but maybe I'm dreaming.
Should be sufficient; for my tests I will just replace the tramp* files.
Thanks, and best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32304
; Package
emacs
.
(Wed, 08 Aug 2018 15:58:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 32304 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: kbrown <at> cornell.edu, 32304 <at> debbugs.gnu.org
> Date: Wed, 08 Aug 2018 17:26:00 +0200
>
> > https://alpha.gnu.org/gnu/emacs/pretest/windows/emacs-27/
> >
> > is from May 4.
>
> I could swear I've checked there, but maybe I'm dreaming.
You've probably looked in
https://alpha.gnu.org/gnu/emacs/windows/
It's tricky ;-)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32304
; Package
emacs
.
(Wed, 08 Aug 2018 18:07:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 32304 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
Hi Eli,
> FAILED 59/63 tramp-test43-auto-load (0.203125 sec)
This must be skipped indeed in your case. It uses
tramp-test-temporary-file-directory, which isn't remote here. I've added
the skip form.
> FAILED 63/63 tramp-test44-unload (0.375000 sec)
This is strange. This test fails only, if most of previous tests didn't
run, like on MS Windows, where almost all tests are skipped. I could
reproduce the error on my GNU/Linux system with
# make -C test tramp-tests SELECTOR='"44"'
This makes it more simple for me to debug. For the time being, I've
tagged the test as :unstable.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32304
; Package
emacs
.
(Thu, 09 Aug 2018 12:25:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 32304 <at> debbugs.gnu.org (full text, mbox):
Michael Albinus <michael.albinus <at> gmx.de> writes:
Hi Eli,
>> FAILED 63/63 tramp-test44-unload (0.375000 sec)
>
> This is strange. This test fails only, if most of previous tests didn't
> run, like on MS Windows, where almost all tests are skipped. I could
> reproduce the error on my GNU/Linux system with
>
> # make -C test tramp-tests SELECTOR='"44"'
>
> This makes it more simple for me to debug. For the time being, I've
> tagged the test as :unstable.
Should be fixed now in master. Could you, pls recheck? (I haven't tested
on MS Windows today)
Thanks, and best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32304
; Package
emacs
.
(Thu, 09 Aug 2018 15:20:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 32304 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: 32304 <at> debbugs.gnu.org
> Date: Thu, 09 Aug 2018 14:24:33 +0200
>
> >> FAILED 63/63 tramp-test44-unload (0.375000 sec)
> >
> > This is strange. This test fails only, if most of previous tests didn't
> > run, like on MS Windows, where almost all tests are skipped. I could
> > reproduce the error on my GNU/Linux system with
> >
> > # make -C test tramp-tests SELECTOR='"44"'
> >
> > This makes it more simple for me to debug. For the time being, I've
> > tagged the test as :unstable.
>
> Should be fixed now in master. Could you, pls recheck? (I haven't tested
> on MS Windows today)
Thanks, it works now as expected.
Reply sent
to
Michael Albinus <michael.albinus <at> gmx.de>
:
You have taken responsibility.
(Fri, 10 Aug 2018 07:28:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Ken Brown <kbrown <at> cornell.edu>
:
bug acknowledged by developer.
(Fri, 10 Aug 2018 07:28:02 GMT)
Full text and
rfc822 format available.
Message #85 received at 32304-done <at> debbugs.gnu.org (full text, mbox):
Version: 27.1
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Should be fixed now in master. Could you, pls recheck? (I haven't tested
>> on MS Windows today)
>
> Thanks, it works now as expected.
Thanks for checking, I'm closing the bug.
Best regards, Michael.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Fri, 07 Sep 2018 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 6 years and 290 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.