GNU bug report logs -
#22145
25.0.50; tramp and auto-revert tests hang on OS X
Previous Next
Reported by: Anders Lindgren <andlind <at> gmail.com>
Date: Fri, 11 Dec 2015 19:22:01 UTC
Severity: normal
Found in version 25.0.50
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 22145 in the body.
You can then email your comments to 22145 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#22145; Package
emacs.
(Fri, 11 Dec 2015 19:22:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Anders Lindgren <andlind <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Fri, 11 Dec 2015 19:22: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)]
On OS X, when running the tests in `test/automated' on the emacs-25 branch,
the tramp and auto-revert tests never terminates.
-- Anders
In GNU Emacs 25.0.50.2 (x86_64-apple-darwin14.5.0, NS appkit-1348.17
Version 10.10.5 (Build 14F27))
of 2015-12-11
Repository revision: 0284660f272a51d17a6f67389a7fa92abf8dec7a
Windowing system distributor 'Apple', version 10.3.1348
Configured using:
'configure --with-ns --without-dbus'
Configured features:
ACL ZLIB TOOLKIT_SCROLL_BARS NS
Important settings:
value of $LC_CTYPE: UTF-8
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Load-path shadows:
None found.
Features:
(shadow sort gnus-util mail-extr emacsbug message dired format-spec
rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util help-fns help-mode easymenu cl-loaddefs pcase cl-lib mail-prsvr
mail-utils time-date mule-util tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel ns-win term/common-win
tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
frame cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan
thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian
slovak czech european ethiopic indian cyrillic chinese charscript
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote cocoa ns multi-tty
make-network-process emacs)
Memory information:
((conses 16 80575 5846)
(symbols 48 18772 0)
(miscs 40 43 120)
(strings 32 13120 4767)
(string-bytes 1 375617)
(vectors 16 10722)
(vector-slots 8 403919 5574)
(floats 8 133 46)
(intervals 56 191 1)
(buffers 976 11))
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Sat, 12 Dec 2015 09:32:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 22145 <at> debbugs.gnu.org (full text, mbox):
Anders Lindgren <andlind <at> gmail.com> writes:
Hi Anders,
> On OS X, when running the tests in `test/automated' on the emacs-25
> branch, the tramp and auto-revert tests never terminates.
Could you pls show the results of
# make -C test/automated auto-revert-tests
# make -C test/automated tramp-tests
> -- Anders
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Sat, 12 Dec 2015 19:00:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 22145 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi!
> Could you pls show the results of
>
> # make -C test/automated auto-revert-tests
>
Apparently, this no longer has a problem.
> # make -C test/automated tramp-tests
>
make: *** test/automated/tramp-tests: No such file or directory. Stop.
macpro:emacs-git-new anders$ make -C test/automated tramp-tests
Compiling tramp-tests.el
Testing tramp-tests.elc
Running 42 tests (2015-12-12 11:04:29+0100)
Remote directory: `/mock::/var/folders/ys/pmyf4b5d58db2y7h89tx0wkm0000gn/T/'
passed 1/42 tramp-test00-availability
passed 2/42 tramp-test01-file-name-syntax
passed 3/42 tramp-test02-file-name-dissect
passed 4/42 tramp-test03-file-name-defaults
passed 5/42 tramp-test04-substitute-in-file-name
passed 6/42 tramp-test05-expand-file-name
passed 7/42 tramp-test06-directory-file-name
passed 8/42 tramp-test07-file-exists-p
passed 9/42 tramp-test08-file-local-copy
passed 10/42 tramp-test09-insert-file-contents
passed 11/42 tramp-test10-write-region
passed 12/42 tramp-test11-copy-file
passed 13/42 tramp-test12-rename-file
passed 14/42 tramp-test13-make-directory
passed 15/42 tramp-test14-delete-directory
passed 16/42 tramp-test15-copy-directory
passed 17/42 tramp-test16-directory-files
passed 18/42 tramp-test17-insert-directory
passed 19/42 tramp-test18-file-attributes
passed 20/42 tramp-test19-directory-files-and-attributes
passed 21/42 tramp-test20-file-modes
passed 22/42 tramp-test21-file-links
passed 23/42 tramp-test22-file-times
passed 24/42 tramp-test23-visited-file-modtime
passed 25/42 tramp-test24-file-name-completion
passed 26/42 tramp-test25-load
passed 27/42 tramp-test26-process-file
passed 28/42 tramp-test27-start-file-process
tramp-test58318B-h
passed 29/42 tramp-test28-shell-command
(Bzr)
Test tramp-test29-vc-registered backtrace:
vc-do-command("*vc*" 0 "bzr" nil "init")
apply(vc-do-command "*vc*" 0 "bzr" nil "init" nil)
vc-bzr-command("init" nil 0 nil)
vc-bzr-create-repo()
apply(vc-bzr-create-repo nil)
vc-call-backend(Bzr create-repo)
vc-create-repo(Bzr)
#[nil "\306\307\310\3073111\312\216\313 \"\211)0\202210\
ert--run-test-internal([cl-struct-ert--test-execution-info [cl-struc
ert-run-test([cl-struct-ert-test tramp-test29-vc-registered "Check `
ert-run-or-rerun-test([cl-struct-ert--stats t [[cl-struct-ert-test t
ert-run-tests(t #[385 "\306\307\"\203G\211\211G\310U\203\211@\20
ert-run-tests-batch(nil)
ert-run-tests-batch-and-exit()
command-line-1(("-L" ":." "-l" "ert" "-l" "tramp-tests.elc" "-f" "er
command-line()
normal-top-level()
Test tramp-test29-vc-registered condition:
(error "Running bzr init ....FAILED (status 1)")
FAILED 30/42 tramp-test29-vc-registered
passed 31/42 tramp-test30-make-auto-save-file-name
passed 32/42 tramp-test31-special-characters
passed 33/42 tramp-test31-special-characters-with-ls
passed 34/42 tramp-test31-special-characters-with-perl
skipped 35/42 tramp-test31-special-characters-with-stat
-- Anders
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Sat, 12 Dec 2015 19:22:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 22145 <at> debbugs.gnu.org (full text, mbox):
Anders Lindgren <andlind <at> gmail.com> writes:
> Hi!
Hi Anders,
> Could you pls show the results of
>
> # make -C test/automated auto-revert-tests
>
> Apparently, this no longer has a problem.
There was a bug indeed in auto-revert-tests.el, which made it freezing
when no file notification was available. This I have fixed a week ago,
commit 8b87522925c4acaa0b35459db2657fc4fc79f8d1. Maybe the error you
have seen predates that patch.
> # make -C test/automated tramp-tests
>
> passed 29/42 tramp-test28-shell-command
> (Bzr)
>
> Test tramp-test29-vc-registered backtrace:
> vc-do-command("*vc*" 0 "bzr" nil "init")
> apply(vc-do-command "*vc*" 0 "bzr" nil "init" nil)
[...]
> Test tramp-test29-vc-registered condition:
> (error "Running bzr init ....FAILED (status 1)")
> FAILED 30/42 tramp-test29-vc-registered
This seems to be rather a vc-bzr error. Shouldn't happen, but this isn't
the cause of the freeze. To be investigated later.
> skipped 35/42 tramp-test31-special-characters-with-stat
The next test, which hangs, is `tramp-test32-utf8'. Hard to debug in
batch mode. Could you, pls, apply the following patch:
--8<---------------cut here---------------start------------->8---
*** /home/albinus/src/emacs-25/test/automated/tramp-tests.el.~emacs-25~ 2015-12-12 20:13:06.844365370 +0100
--- /home/albinus/src/emacs-25/test/automated/tramp-tests.el 2015-12-12 20:12:01.987541309 +0100
***************
*** 2031,2037 ****
"Check UTF8 encoding in file names and file contents."
(skip-unless (tramp--test-enabled))
! (tramp--test-utf8))
(ert-deftest tramp-test32-utf8-with-stat ()
"Check UTF8 encoding in file names and file contents.
--- 2031,2038 ----
"Check UTF8 encoding in file names and file contents."
(skip-unless (tramp--test-enabled))
! (tramp--instrument-test-case 10
! (tramp--test-utf8)))
(ert-deftest tramp-test32-utf8-with-stat ()
"Check UTF8 encoding in file names and file contents.
--8<---------------cut here---------------end--------------->8---
Eval tramp-tests.el. Afterwards, apply
M-x ert <RET> tramp-test32-utf8 <RET>
Wait a while until you know for sure it hangs. Apply C-g. Move the
cursor over the "tramp-test32-utf8" string in the *ert* buffer, and
press m. You will see the *ERT Messages* buffer, pls show.
> -- Anders
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Sat, 12 Dec 2015 21:07:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 22145 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>
> There was a bug indeed in auto-revert-tests.el, which made it freezing
> when no file notification was available. This I have fixed a week ago,
> commit 8b87522925c4acaa0b35459db2657fc4fc79f8d1. Maybe the error you
> have seen predates that patch.
>
That could have been it.
> > # make -C test/automated tramp-tests
> Wait a while until you know for sure it hangs. Apply C-g. Move the
> cursor over the "tramp-test32-utf8" string in the *ert* buffer, and
> press m. You will see the *ERT Messages* buffer, pls show.
It just gave me a "ert--stats-test-pos: Wrong type argument: arrayp, nil"...
Anyway, I've attached the content of the *Messages* buffer, hopefully, it
will contain whatever you were looking for. Please let me know if you need
more information.
-- Anders
[Message part 2 (text/html, inline)]
[log.txt (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Sun, 13 Dec 2015 09:03:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 22145 <at> debbugs.gnu.org (full text, mbox):
Anders Lindgren <andlind <at> gmail.com> writes:
> > # make -C test/automated tramp-tests
> Wait a while until you know for sure it hangs. Apply C-g. Move the
> cursor over the "tramp-test32-utf8" string in the *ert* buffer,
> and
> press m. You will see the *ERT Messages* buffer, pls show.
>
> It just gave me a "ert--stats-test-pos: Wrong type argument: arrayp,
> nil"...
>
> Anyway, I've attached the content of the *Messages* buffer, hopefully,
> it will contain whatever you were looking for. Please let me know if
> you need more information.
It's only part of the whole story (the last 1000 lines due to
message-log-max), but it helps.
Tramp hangs at this command:
--8<---------------cut here---------------start------------->8---
# (test -e /private/var/folders/ys/pmyf4b5d58db2y7h89tx0wkm0000gn/T/tramp-test71335Nhl/\أ\ص\ب\ح\ \ب\و\س\ع\ك\ \ا\ل\آ\ن\ \ت\ن\ز\ي\ل\ \ن\س\خ\ة\ \ك\ا\م\ل\ة\ \م\ن\ \م\و\س\و\ع\ة\ \و\ي\ك\ي\ب\ي\د\ي\ا\ \ا\ل\ع\ر\ب\ي\ة\ \ل\ت\ص\ف\ح\ه\ا\ \ب\ل\ا\ \ا\ت\ص\ا\ل\ \ب\ا\ل\إ\ن\ت\ر\ن\ت || test -h /private/var/folders/ys/pmyf4b5d58db2y7h89tx0wkm0000gn/T/tramp-test71335Nhl/\أ\ص\ب\ح\ \ب\و\س\ع\ك\ \ا\ل\آ\ن\ \ت\ن\ز\ي\ل\ \ن\س\خ\ة\ \ك\ا\م\ل\ة\ \م\ن\ \م\و\س\و\ع\ة\ \و\ي\ك\ي\ب\ي\د\ي\ا\ \ا\ل\ع\ر\ب\ي\ة\ \ل\ت\ص\ف\ح\ه\ا\ \ب\ل\ا\ \ا\ت\ص\ا\ل\ \ب\ا\ل\إ\ن\ت\ر\ن\ت) && /bin/ls -w -ildn /private/var/folders/ys/pmyf4b5d58db2y7h89tx0wkm0000gn/T/tramp-test71335Nhl/\أ\ص\ب\ح\ \ب\و\س\ع\ك\ \ا\ل\آ\ن\ \ت\ن\ز\ي\ل\ \ن\س\خ\ة\ \ك\ا\م\ل\ة\ \م\ن\ \م\و\س\و\ع\ة\ \و\ي\ك\ي\ب\ي\د\ي\ا\ \ا\ل\ع\ر\ب\ي\ة\ \ل\ت\ص\ف\ح\ه\ا\ \ب\ل\ا\ \ا\ت\ص\ا\ل\ \ب\ا\ل\إ\ن\ت\ر\ن\ت
--8<---------------cut here---------------end--------------->8---
This is a delicate command, because the file name is r2l encoded, and
one aim of the test is to check whether this works. OTOH, I see ^G
evidences in the trace after sending the command, so I don't know
whether Tramp really hangs, or whether this has been the place you have
started to interrupt the test.
Could you, pls, run the command in a shell buffer on your machine? At
this state of the test the file doesn't exist yet, so we could use a
shorter directory path. Something like
--8<---------------cut here---------------start------------->8---
# (test -e /tmp/\أ\ص\ب\ح\ \ب\و\س\ع\ك\ \ا\ل\آ\ن\ \ت\ن\ز\ي\ل\ \ن\س\خ\ة\ \ك\ا\م\ل\ة\ \م\ن\ \م\و\س\و\ع\ة\ \و\ي\ك\ي\ب\ي\د\ي\ا\ \ا\ل\ع\ر\ب\ي\ة\ \ل\ت\ص\ف\ح\ه\ا\ \ب\ل\ا\ \ا\ت\ص\ا\ل\ \ب\ا\ل\إ\ن\ت\ر\ن\ت || test -h /tmp/\أ\ص\ب\ح\ \ب\و\س\ع\ك\ \ا\ل\آ\ن\ \ت\ن\ز\ي\ل\ \ن\س\خ\ة\ \ك\ا\م\ل\ة\ \م\ن\ \م\و\س\و\ع\ة\ \و\ي\ك\ي\ب\ي\د\ي\ا\ \ا\ل\ع\ر\ب\ي\ة\ \ل\ت\ص\ف\ح\ه\ا\ \ب\ل\ا\ \ا\ت\ص\ا\ل\ \ب\ا\ل\إ\ن\ت\ر\ن\ت) && /bin/ls -w -ildn /tmp/\أ\ص\ب\ح\ \ب\و\س\ع\ك\ \ا\ل\آ\ن\ \ت\ن\ز\ي\ل\ \ن\س\خ\ة\ \ك\ا\م\ل\ة\ \م\ن\ \م\و\س\و\ع\ة\ \و\ي\ك\ي\ب\ي\د\ي\ا\ \ا\ل\ع\ر\ب\ي\ة\ \ل\ت\ص\ف\ح\ه\ا\ \ب\ل\ا\ \ا\ت\ص\ا\ل\ \ب\ا\ل\إ\ن\ت\ر\ن\ت
--8<---------------cut here---------------end--------------->8---
And if this hangs, mybe also the test -e ... and test -h ... command alone.
> -- Anders
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Sun, 13 Dec 2015 15:37:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 22145 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Date: Sun, 13 Dec 2015 10:02:34 +0100
> Cc: 22145 <at> debbugs.gnu.org
>
> --8<---------------cut here---------------start------------->8---
> # (test -e /private/var/folders/ys/pmyf4b5d58db2y7h89tx0wkm0000gn/T/tramp-test71335Nhl/\أ\ص\ب\ح\ \ب\و\س\ع\ك\ \ا\ل\آ\ن\ \ت\ن\ز\ي\ل\ \ن\س\خ\ة\ \ك\ا\م\ل\ة\ \م\ن\ \م\و\س\و\ع\ة\ \و\ي\ك\ي\ب\ي\د\ي\ا\ \ا\ل\ع\ر\ب\ي\ة\ \ل\ت\ص\ف\ح\ه\ا\ \ب\ل\ا\ \ا\ت\ص\ا\ل\ \ب\ا\ل\إ\ن\ت\ر\ن\ت || test -h /private/var/folders/ys/pmyf4b5d58db2y7h89tx0wkm0000gn/T/tramp-test71335Nhl/\أ\ص\ب\ح\ \ب\و\س\ع\ك\ \ا\ل\آ\ن\ \ت\ن\ز\ي\ل\ \ن\س\خ\ة\ \ك\ا\م\ل\ة\ \م\ن\ \م\و\س\و\ع\ة\ \و\ي\ك\ي\ب\ي\د\ي\ا\ \ا\ل\ع\ر\ب\ي\ة\ \ل\ت\ص\ف\ح\ه\ا\ \ب\ل\ا\ \ا\ت\ص\ا\ل\ \ب\ا\ل\إ\ن\ت\ر\ن\ت) && /bin/ls -w -ildn /private/var/folders/ys/pmyf4b5d58db2y7h89tx0wkm0000gn/T/tramp-test71335Nhl/\أ\ص\ب\ح\ \ب\و\س\ع\ك\ \ا\ل\آ\ن\ \ت\ن\ز\ي\ل\ \ن\س\خ\ة\ \ك\ا\م\ل\ة\ \م\ن\ \م\و\س\و\ع\ة\ \و\ي\ك\ي\ب\ي\د\ي\ا\ \ا\ل\ع\ر\ب\ي\ة\ \ل\ت\ص\ف\ح\ه\ا\ \ب\ل\ا\ \ا\ت\ص\ا\ل\ \ب\ا\ل\إ\ن\ت\ر\ن\ت
> --8<---------------cut here---------------end--------------->8---
>
> This is a delicate command, because the file name is r2l encoded, and
> one aim of the test is to check whether this works. OTOH, I see ^G
> evidences in the trace after sending the command, so I don't know
> whether Tramp really hangs, or whether this has been the place you have
> started to interrupt the test.
Since this is OS X, the normalization used by its filesystem could
also be a factor.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Sun, 13 Dec 2015 21:45:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 22145 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi!
When executing the command line in a shell window, they terminate
immediately without any output. Also, this is the case when running the
individual `test' commands.
I mananged to get the "m" command working by placing the point on the "Q"
in the ert status line, I have attached the result.
-- Anders
2015-12-13 10:02 GMT+01:00 Michael Albinus <michael.albinus <at> gmx.de>:
> Anders Lindgren <andlind <at> gmail.com> writes:
>
> > > # make -C test/automated tramp-tests
> > Wait a while until you know for sure it hangs. Apply C-g. Move the
> > cursor over the "tramp-test32-utf8" string in the *ert* buffer,
> > and
> > press m. You will see the *ERT Messages* buffer, pls show.
> >
> > It just gave me a "ert--stats-test-pos: Wrong type argument: arrayp,
> > nil"...
> >
> > Anyway, I've attached the content of the *Messages* buffer, hopefully,
> > it will contain whatever you were looking for. Please let me know if
> > you need more information.
>
> It's only part of the whole story (the last 1000 lines due to
> message-log-max), but it helps.
>
> Tramp hangs at this command:
>
> --8<---------------cut here---------------start------------->8---
> # (test -e
> /private/var/folders/ys/pmyf4b5d58db2y7h89tx0wkm0000gn/T/tramp-test71335Nhl/\أ\ص\ب\ح\
> \ب\و\س\ع\ك\ \ا\ل\آ\ن\ \ت\ن\ز\ي\ل\ \ن\س\خ\ة\ \ك\ا\م\ل\ة\ \م\ن\ \م\و\س\و\ع\ة\
> \و\ي\ك\ي\ب\ي\د\ي\ا\ \ا\ل\ع\ر\ب\ي\ة\ \ل\ت\ص\ف\ح\ه\ا\ \ب\ل\ا\ \ا\ت\ص\ا\ل\
> \ب\ا\ل\إ\ن\ت\ر\ن\ت || test -h
> /private/var/folders/ys/pmyf4b5d58db2y7h89tx0wkm0000gn/T/tramp-test71335Nhl/\أ\ص\ب\ح\
> \ب\و\س\ع\ك\ \ا\ل\آ\ن\ \ت\ن\ز\ي\ل\ \ن\س\خ\ة\ \ك\ا\م\ل\ة\ \م\ن\ \م\و\س\و\ع\ة\
> \و\ي\ك\ي\ب\ي\د\ي\ا\ \ا\ل\ع\ر\ب\ي\ة\ \ل\ت\ص\ف\ح\ه\ا\ \ب\ل\ا\ \ا\ت\ص\ا\ل\
> \ب\ا\ل\إ\ن\ت\ر\ن\ت) && /bin/ls -w -ildn
> /private/var/folders/ys/pmyf4b5d58db2y7h89tx0wkm0000gn/T/tramp-test71335Nhl/\أ\ص\ب\ح\
> \ب\و\س\ع\ك\ \ا\ل\آ\ن\ \ت\ن\ز\ي\ل\ \ن\س\خ\ة\ \ك\ا\م\ل\ة\ \م\ن\ \م\و\س\و\ع\ة\
> \و\ي\ك\ي\ب\ي\د\ي\ا\ \ا\ل\ع\ر\ب\ي\ة\ \ل\ت\ص\ف\ح\ه\ا\ \ب\ل\ا\ \ا\ت\ص\ا\ل\
> \ب\ا\ل\إ\ن\ت\ر\ن\ت
> --8<---------------cut here---------------end--------------->8---
>
> This is a delicate command, because the file name is r2l encoded, and
> one aim of the test is to check whether this works. OTOH, I see ^G
> evidences in the trace after sending the command, so I don't know
> whether Tramp really hangs, or whether this has been the place you have
> started to interrupt the test.
>
> Could you, pls, run the command in a shell buffer on your machine? At
> this state of the test the file doesn't exist yet, so we could use a
> shorter directory path. Something like
>
> --8<---------------cut here---------------start------------->8---
> # (test -e /tmp/\أ\ص\ب\ح\ \ب\و\س\ع\ك\ \ا\ل\آ\ن\ \ت\ن\ز\ي\ل\ \ن\س\خ\ة\
> \ك\ا\م\ل\ة\ \م\ن\ \م\و\س\و\ع\ة\ \و\ي\ك\ي\ب\ي\د\ي\ا\ \ا\ل\ع\ر\ب\ي\ة\
> \ل\ت\ص\ف\ح\ه\ا\ \ب\ل\ا\ \ا\ت\ص\ا\ل\ \ب\ا\ل\إ\ن\ت\ر\ن\ت || test -h
> /tmp/\أ\ص\ب\ح\ \ب\و\س\ع\ك\ \ا\ل\آ\ن\ \ت\ن\ز\ي\ل\ \ن\س\خ\ة\ \ك\ا\م\ل\ة\
> \م\ن\ \م\و\س\و\ع\ة\ \و\ي\ك\ي\ب\ي\د\ي\ا\ \ا\ل\ع\ر\ب\ي\ة\ \ل\ت\ص\ف\ح\ه\ا\
> \ب\ل\ا\ \ا\ت\ص\ا\ل\ \ب\ا\ل\إ\ن\ت\ر\ن\ت) && /bin/ls -w -ildn /tmp/\أ\ص\ب\ح\
> \ب\و\س\ع\ك\ \ا\ل\آ\ن\ \ت\ن\ز\ي\ل\ \ن\س\خ\ة\ \ك\ا\م\ل\ة\ \م\ن\ \م\و\س\و\ع\ة\
> \و\ي\ك\ي\ب\ي\د\ي\ا\ \ا\ل\ع\ر\ب\ي\ة\ \ل\ت\ص\ف\ح\ه\ا\ \ب\ل\ا\ \ا\ت\ص\ا\ل\
> \ب\ا\ل\إ\ن\ت\ر\ن\ت
> --8<---------------cut here---------------end--------------->8---
>
> And if this hangs, mybe also the test -e ... and test -h ... command alone.
>
> > -- Anders
>
> Best regards, Michael.
>
[Message part 2 (text/html, inline)]
[log2.txt (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Tue, 15 Dec 2015 11:34:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 22145 <at> debbugs.gnu.org (full text, mbox):
Anders Lindgren <andlind <at> gmail.com> writes:
> Hi!
Hi Anders,
> When executing the command line in a shell window, they terminate
> immediately without any output. Also, this is the case when running
> the individual `test' commands.
>
> I mananged to get the "m" command working by placing the point on the
> "Q" in the ert status line, I have attached the result.
Thanks. The ^G output starts after the same command we have discussed
last time, it is not due to your interruption. Likely, the remote
machine rings the bell in order to tell us something. Hmm.
However, the full traces show at least two problems during the
connection initialization:
> 21:26:49.079747 tramp-open-connection-setup-interactive-shell (5) # Setting coding system to ‘utf-8’ and ‘utf-8-unix’
This shows the settings for `process-coding-system'. The encoding
setting shall not use unix eol conversion.
> 21:26:49.196018 tramp-send-command (6) # stty -a
> 21:26:49.200446 tramp-wait-for-regexp (6) #
> speed 9600 baud; 0 rows; 0 columns;
> lflags: icanon isig iexten -echo echoe -echok echoke -echonl echoctl
> -echoprt -altwerase -noflsh -tostop -flusho -pendin -nokerninfo
> -extproc
> iflags: -istrip icrnl -inlcr -igncr ixon -ixoff ixany imaxbel -iutf8
> -ignbrk brkint -inpck -ignpar -parmrk
> oflags: opost -onlcr -oxtabs -onocr -onlret
> cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow
> -dtrflow -mdmbuf
> cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = <undef>;
> eol2 = <undef>; erase = ^H; intr = ^C; kill = ^U; lnext = ^V;
> min = 1; quit = ^\; reprint = ^R; start = ^Q; status = ^T;
> stop = ^S; susp = ^Z; time = 0; werase = ^W;
As you see, stty uses -iutf8. Don't know, whether this results in
problems. What's the output of "stty -a" in your terminal?
I have committed a patch to the emacs-25 branch, which shall set the
process encoding to `utf-8-mac'. Could you, pls, check? In case it
doesn't work, pls send the whole traces again that I can check whether
the patch did apply correctly (I cannot test on OS X). If not, we could
try to change tty settings.
> -- Anders
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Tue, 15 Dec 2015 19:57:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 22145 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
As you see, stty uses -iutf8. Don't know, whether this results in
> problems. What's the output of "stty -a" in your terminal?
>
speed 9600 baud; 24 rows; 80 columns;
lflags: icanon isig iexten echo echoe -echok echoke -echonl echoctl
-echoprt -altwerase -noflsh -tostop -flusho pendin -nokerninfo
-extproc
iflags: -istrip icrnl -inlcr -igncr ixon -ixoff ixany imaxbel iutf8
-ignbrk brkint -inpck -ignpar -parmrk
oflags: opost onlcr -oxtabs -onocr -onlret
cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow
-dtrflow -mdmbuf
cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = <undef>;
eol2 = <undef>; erase = ^?; intr = ^C; kill = ^U; lnext = ^V;
min = 1; quit = ^\; reprint = ^R; start = ^Q; status = ^T;
stop = ^S; susp = ^Z; time = 0; werase = ^W;
> I have committed a patch to the emacs-25 branch, which shall set the
> process encoding to `utf-8-mac'. Could you, pls, check? In case it
> doesn't work, pls send the whole traces again that I can check whether
> the patch did apply correctly (I cannot test on OS X). If not, we could
> try to change tty settings.
>
I just ran the updated test. Unfortunately, the tramp tests still hang.
I have attached the log of tramp-test32-utf8.
-- Anders
[Message part 2 (text/html, inline)]
[ert2.log (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Tue, 15 Dec 2015 22:59:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 22145 <at> debbugs.gnu.org (full text, mbox):
Anders Lindgren <andlind <at> gmail.com> writes:
> Hi,
Hi Anders,
> As you see, stty uses -iutf8. Don't know, whether this results in
> problems. What's the output of "stty -a" in your terminal?
>
> iflags: -istrip icrnl -inlcr -igncr ixon -ixoff ixany imaxbel iutf8
Here the setting is correct, iutf8.
> I just ran the updated test. Unfortunately, the tramp tests still
> hang.
OK, phase 2. I've committed another patch which sets iutf8. Pls check,
whether this helps.
> -- Anders
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Wed, 16 Dec 2015 06:27:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 22145 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
Unfortunately, it still hangs.
-- Anders
On Tue, Dec 15, 2015 at 11:57 PM, Michael Albinus <michael.albinus <at> gmx.de>
wrote:
> Anders Lindgren <andlind <at> gmail.com> writes:
>
> > Hi,
>
> Hi Anders,
>
> > As you see, stty uses -iutf8. Don't know, whether this results in
> > problems. What's the output of "stty -a" in your terminal?
> >
> > iflags: -istrip icrnl -inlcr -igncr ixon -ixoff ixany imaxbel iutf8
>
> Here the setting is correct, iutf8.
>
> > I just ran the updated test. Unfortunately, the tramp tests still
> > hang.
>
> OK, phase 2. I've committed another patch which sets iutf8. Pls check,
> whether this helps.
>
> > -- Anders
>
> Best regards, Michael.
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Wed, 16 Dec 2015 22:40:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 22145 <at> debbugs.gnu.org (full text, mbox):
Anders Lindgren <andlind <at> gmail.com> writes:
> Hi,
Hi Anders,
> Unfortunately, it still hangs.
I'm running out of ideas. Maybe I should simply suppress this test for
OSX ...
> -- Anders
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Thu, 17 Dec 2015 19:39:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 22145 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
I tried to see what actually happened in the test cases.
I seem to have boiled things down to the following line, when evaluated,
tramp hangs. When enabling debug-on-quit, I get the attached backtrace
after hitting C-g.
(write-region "test" nil
"/mock:anders-lindgrens-macbook.local:/private/var/folders/qq/qqGPPGoBHOGgJs3oBoKTHU+++TI/-Tmp-/tramp-test1900-Fy/test")
The directory exists and is empty.
It looks like the code tries to run an external command "mock" (which
doesn't exits, as far as I know).
-- Anders
On Wed, Dec 16, 2015 at 11:39 PM, Michael Albinus <michael.albinus <at> gmx.de>
wrote:
> Anders Lindgren <andlind <at> gmail.com> writes:
>
> > Hi,
>
> Hi Anders,
>
> > Unfortunately, it still hangs.
>
> I'm running out of ideas. Maybe I should simply suppress this test for
> OSX ...
>
> > -- Anders
>
> Best regards, Michael.
>
[Message part 2 (text/html, inline)]
[tramp-bt3.txt (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Fri, 18 Dec 2015 08:13:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 22145 <at> debbugs.gnu.org (full text, mbox):
Anders Lindgren <andlind <at> gmail.com> writes:
> Hi,
Hi Anders,
> I tried to see what actually happened in the test cases.
>
> I seem to have boiled things down to the following line, when
> evaluated, tramp hangs. When enabling debug-on-quit, I get the
> attached backtrace after hitting C-g.
>
> (write-region "test" nil
> "/mock:anders-lindgrens-macbook.local:/private/var/folders/qq/qqGPPGoBHOGgJs3oBoKTHU+++TI/-Tmp-/tramp-test1900-Fy/test")
>
>
> The directory exists and is empty.
>
> It looks like the code tries to run an external command "mock" (which
> doesn't exits, as far as I know).
Nope. "mock" is not a command. It is a fake (mock) Tramp method I create
on-the-fly when running tramp-test.el. This is because I cannot use any
real Tramp method, because usually they require user authentication,
which is a no-go for tests running in batch mode.
According to your backtrace, you have interrupted Tramp at the following
place:
> Debugger entered--Lisp error: (quit)
> accept-process-output(#<process *tramp/mock anders-lindgrens-macbook.local*> 1 nil t)
> tramp-accept-process-output(#<process *tramp/mock anders-lindgrens-macbook.local*> 1)
> tramp-wait-for-regexp(#<process *tramp/mock anders-lindgrens-macbook.local*> nil "\\(^\\|\\)[^#$\n]*///9132fe7dc760b6d1120df52ca7cc56ca#\\$?$")
> tramp-wait-for-output(#<process *tramp/mock anders-lindgrens-macbook.local*>)
> tramp-send-command(["mock" nil "anders-lindgrens-macbook.local" "/private/var/folders/qq/qqGPPGoBHOGgJs3oBoKTHU+++TI/-Tmp-/tramp-test1900-Fy/test" nil] "echo \\\"`getconf PATH 2>/dev/null`\\\" 2>/dev/null; echo tramp_exit_status $?")
This is the command "echo \\\"`getconf PATH 2>/dev/null`\\\"
2>/dev/null; echo tramp_exit_status $?", which shouldn't fail. At least
it didn't fail so far.
Could you send the full Tramp traces? Maybe my last change has damaged
something else.
> -- Anders
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Fri, 18 Dec 2015 19:56:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 22145 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
The cases I found didn't occur when running under `ert', because then I
could not manage to break into the debugger.
However, today I tested with `debug-on-quit' to t and `ert-debug-on-error'.
When I press C-g I go into the debugger and it looks like it's executing
the `test' commands you suggested earlier. I've attached the backtrace (for
what's it worth).
Anyway, it works with simple filenames like "xyz", so it is somehow
connected to the non-ascii file names. By the way, are you aware that OS X
denormalizes file names when stored in the file system, could that be
related to this in any way?
-- Anders
On Fri, Dec 18, 2015 at 9:12 AM, Michael Albinus <michael.albinus <at> gmx.de>
wrote:
> Anders Lindgren <andlind <at> gmail.com> writes:
>
> > Hi,
>
> Hi Anders,
>
> > I tried to see what actually happened in the test cases.
> >
> > I seem to have boiled things down to the following line, when
> > evaluated, tramp hangs. When enabling debug-on-quit, I get the
> > attached backtrace after hitting C-g.
> >
> > (write-region "test" nil
> >
> "/mock:anders-lindgrens-macbook.local:/private/var/folders/qq/qqGPPGoBHOGgJs3oBoKTHU+++TI/-Tmp-/tramp-test1900-Fy/test")
> >
> >
> > The directory exists and is empty.
> >
> > It looks like the code tries to run an external command "mock" (which
> > doesn't exits, as far as I know).
>
> Nope. "mock" is not a command. It is a fake (mock) Tramp method I create
> on-the-fly when running tramp-test.el. This is because I cannot use any
> real Tramp method, because usually they require user authentication,
> which is a no-go for tests running in batch mode.
>
> According to your backtrace, you have interrupted Tramp at the following
> place:
>
> > Debugger entered--Lisp error: (quit)
> > accept-process-output(#<process *tramp/mock
> anders-lindgrens-macbook.local*> 1 nil t)
> > tramp-accept-process-output(#<process *tramp/mock
> anders-lindgrens-macbook.local*> 1)
> > tramp-wait-for-regexp(#<process *tramp/mock
> anders-lindgrens-macbook.local*> nil
> "\\(^\\|\\)[^#$\n]*///9132fe7dc760b6d1120df52ca7cc56ca#\\$?$")
> > tramp-wait-for-output(#<process *tramp/mock
> anders-lindgrens-macbook.local*>)
> > tramp-send-command(["mock" nil "anders-lindgrens-macbook.local"
> "/private/var/folders/qq/qqGPPGoBHOGgJs3oBoKTHU+++TI/-Tmp-/tramp-test1900-Fy/test"
> nil] "echo \\\"`getconf PATH 2>/dev/null`\\\" 2>/dev/null; echo
> tramp_exit_status $?")
>
> This is the command "echo \\\"`getconf PATH 2>/dev/null`\\\"
> 2>/dev/null; echo tramp_exit_status $?", which shouldn't fail. At least
> it didn't fail so far.
>
> Could you send the full Tramp traces? Maybe my last change has damaged
> something else.
>
> > -- Anders
>
> Best regards, Michael.
>
[Message part 2 (text/html, inline)]
[tramp-bt4.txt (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Sat, 19 Dec 2015 19:25:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 22145 <at> debbugs.gnu.org (full text, mbox):
Anders Lindgren <andlind <at> gmail.com> writes:
> Anyway, it works with simple filenames like "xyz", so it is somehow
> connected to the non-ascii file names. By the way, are you aware that
> OS X denormalizes file names when stored in the file system, could
> that be related to this in any way?
Yes, I follow your discussion with Eli. But I don't see (yet) how it is
related to Tramp. Tramp works on shell level, and you have proved in the
very beginning of our conversation, that the command itself works when
entered in the shell.
So I still have no real idea. Maybe (attention: wild guess!) the shell
command or a path of this command is too long for OSX? So we might try
to run the command as-it-is. Could you pls check, what happens in a
shell with these commands:
--8<---------------cut here---------------start------------->8---
# mkdir /private/var/folders/qq/qqGPPGoBHOGgJs3oBoKTHU\\+\\+\\+TI/-Tmp-/tramp-test22198dkQ
# (test -e /private/var/folders/qq/qqGPPGoBHOGgJs3oBoKTHU\\+\\+\\+TI/-Tmp-/tramp-test22198dkQ/\\أ\\ص\\ب\\ح\\ \\ب\\و\\س\\ع\\ك\\ \\ا\\ل\\آ\\ن\\ \\ت\\ن\\ز\\ي\\ل\\ \\ن\\س\\خ\\ة\\ \\ك\\ا\\م\\ل\\ة\\ \\م\\ن\\ \\م\\و\\س\\و\\ع\\ة\\ \\و\\ي\\ك\\ي\\ب\\ي\\د\\ي\\ا\\ \\ا\\ل\\ع\\ر\\ب\\ي\\ة\\ \\ل\\ت\\ص\\ف\\ح\\ه\\ا\\ \\ب\\ل\\ا\\ \\ا\\ت\\ص\\ا\\ل\\ \\ب\\ا\\ل\\إ\\ن\\ت\\ر\\ن\\ت || test -h /private/var/folders/qq/qqGPPGoBHOGgJs3oBoKTHU\\+\\+\\+TI/-Tmp-/tramp-test22198dkQ/\\أ\\ص\\ب\\ح\\ \\ب\\و\\س\\ع\\ك\\ \\ا\\ل\\آ\\ن\\ \\ت\\ن\\ز\\ي\\ل\\ \\ن\\س\\خ\\ة\\ \\ك\\ا\\م\\ل\\ة\\ \\م\\ن\\ \\م\\و\\س\\و\\ع\\ة\\ \\و\\ي\\ك\\ي\\ب\\ي\\د\\ي\\ا\\ \\ا\\ل\\ع\\ر\\ب\\ي\\ة\\ \\ل\\ت\\ص\\ف\\ح\\ه\\ا\\ \\ب\\ل\\ا\\ \\ا\\ت\\ص\\ا\\ل\\ \\ب\\ا\\ل\\إ\\ن\\ت\\ر\\ن\\ت) && /bin/ls -ildn -w /private/var/folders/qq/qqGPPGoBHOGgJs3oBoKTHU\\+\\+\\+TI/-Tmp-/tramp-test22198dkQ/\\أ\\ص\\ب\\ح\\ \\ب\\و\\س\\ع\\ك\\ \\ا\\ل\\آ\\ن\\ \\ت\\ن\\ز\\ي\\ل\\ \\ن\\س\\خ\\ة\\ \\ك\\ا\\م\\ل\\ة\\ \\م\\ن\\ \\م\\و\\س\\و\\ع\\ة\\ \\و\\ي\\ك\\ي\\ب\\ي\\د\\ي\\ا\\ \\ا\\ل\\ع\\ر\\ب\\ي\\ة\\ \\ل\\ت\\ص\\ف\\ح\\ه\\ا\\ \\ب\\ل\\ا\\ \\ا\\ت\\ص\\ا\\ل\\ \\ب\\ا\\ل\\إ\\ن\\ت\\ر\\ن\\ت
--8<---------------cut here---------------end--------------->8---
Pls check also, whether you here a beep from your machine. We have seen
^G's in the Tramp debug buffer ...
> -- Anders
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Sat, 19 Dec 2015 22:44:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 22145 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I get:
-bash: test: too many arguments
-bash: test: too many arguments
I didn't see any beeps in the output (I even checked with "od -a").
OS X Yosemite comes with bash 3.2.57 (from 2007) -- so it might not be up
to speed when it comes to parsing the command line with odd characters.
(Just a theory, but I thought it would be worth pointing it out.)
-- Anders
On Sat, Dec 19, 2015 at 8:24 PM, Michael Albinus <michael.albinus <at> gmx.de>
wrote:
>
> Anders Lindgren <andlind <at> gmail.com> writes:
>
> > Anyway, it works with simple filenames like "xyz", so it is somehow
> > connected to the non-ascii file names. By the way, are you aware that
> > OS X denormalizes file names when stored in the file system, could
> > that be related to this in any way?
>
> Yes, I follow your discussion with Eli. But I don't see (yet) how it is
> related to Tramp. Tramp works on shell level, and you have proved in the
> very beginning of our conversation, that the command itself works when
> entered in the shell.
>
> So I still have no real idea. Maybe (attention: wild guess!) the shell
> command or a path of this command is too long for OSX? So we might try
> to run the command as-it-is. Could you pls check, what happens in a
> shell with these commands:
>
> --8<---------------cut here---------------start------------->8---
> # mkdir
/private/var/folders/qq/qqGPPGoBHOGgJs3oBoKTHU\\+\\+\\+TI/-Tmp-/tramp-test22198dkQ
> # (test -e
/private/var/folders/qq/qqGPPGoBHOGgJs3oBoKTHU\\+\\+\\+TI/-Tmp-/tramp-test22198dkQ/\\أ\\ص\\ب\\ح\\
\\ب\\و\\س\\ع\\ك\\ \\ا\\ل\\آ\\ن\\ \\ت\\ن\\ز\\ي\\ل\\ \\ن\\س\\خ\\ة\\
\\ك\\ا\\م\\ل\\ة\\ \\م\\ن\\ \\م\\و\\س\\و\\ع\\ة\\
\\و\\ي\\ك\\ي\\ب\\ي\\د\\ي\\ا\\ \\ا\\ل\\ع\\ر\\ب\\ي\\ة\\
\\ل\\ت\\ص\\ف\\ح\\ه\\ا\\ \\ب\\ل\\ا\\ \\ا\\ت\\ص\\ا\\ل\\
\\ب\\ا\\ل\\إ\\ن\\ت\\ر\\ن\\ت || test -h
/private/var/folders/qq/qqGPPGoBHOGgJs3oBoKTHU\\+\\+\\+TI/-Tmp-/tramp-test22198dkQ/\\أ\\ص\\ب\\ح\\
\\ب\\و\\س\\ع\\ك\\ \\ا\\ل\\آ\\ن\\ \\ت\\ن\\ز\\ي\\ل\\ \\ن\\س\\خ\\ة\\
\\ك\\ا\\م\\ل\\ة\\ \\م\\ن\\ \\م\\و\\س\\و\\ع\\ة\\
\\و\\ي\\ك\\ي\\ب\\ي\\د\\ي\\ا\\ \\ا\\ل\\ع\\ر\\ب\\ي\\ة\\
\\ل\\ت\\ص\\ف\\ح\\ه\\ا\\ \\ب\\ل\\ا\\ \\ا\\ت\\ص\\ا\\ل\\
\\ب\\ا\\ل\\إ\\ن\\ت\\ر\\ن\\ت) && /bin/ls -ildn -w
/private/var/folders/qq/qqGPPGoBHOGgJs3oBoKTHU\\+\\+\\+TI/-Tmp-/tramp-test22198dkQ/\\أ\\ص\\ب\\ح\\
\\ب\\و\\س\\ع\\ك\\ \\ا\\ل\\آ\\ن\\ \\ت\\ن\\ز\\ي\\ل\\ \\ن\\س\\خ\\ة\\
\\ك\\ا\\م\\ل\\ة\\ \\م\\ن\\ \\م\\و\\س\\و\\ع\\ة\\
\\و\\ي\\ك\\ي\\ب\\ي\\د\\ي\\ا\\ \\ا\\ل\\ع\\ر\\ب\\ي\\ة\\
\\ل\\ت\\ص\\ف\\ح\\ه\\ا\\ \\ب\\ل\\ا\\ \\ا\\ت\\ص\\ا\\ل\\
\\ب\\ا\\ل\\إ\\ن\\ت\\ر\\ن\\ت
> --8<---------------cut here---------------end--------------->8---
>
> Pls check also, whether you here a beep from your machine. We have seen
> ^G's in the Tramp debug buffer ...
>
> > -- Anders
>
> Best regards, Michael.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Sun, 20 Dec 2015 12:31:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 22145 <at> debbugs.gnu.org (full text, mbox):
Anders Lindgren <andlind <at> gmail.com> writes:
> I get:
>
> -bash: test: too many arguments
> -bash: test: too many arguments
Hmm. This is unexpected. And Tramp would see such errors; it is trained
to detect failed commands. Maybe a cut'n'paste error?
> I didn't see any beeps in the output (I even checked with "od -a").
>
> OS X Yosemite comes with bash 3.2.57 (from 2007) -- so it might not be
> up to speed when it comes to parsing the command line with odd
> characters. (Just a theory, but I thought it would be worth pointing
> it out.)
So maybe another ls is used than the one I check? Since I have no OS X
machine, I read the man page at
<https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/ls.1.html>.
Does your ls behaves like this? The "-w" option is important.
> -- Anders
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Sun, 20 Dec 2015 15:39:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 22145 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>
> > I get:
> >
> > -bash: test: too many arguments
> > -bash: test: too many arguments
>
> Hmm. This is unexpected. And Tramp would see such errors; it is trained
> to detect failed commands. Maybe a cut'n'paste error?
>
Could be. Could you send the commands in an attachment.
> I didn't see any beeps in the output (I even checked with "od -a").
> >
> > OS X Yosemite comes with bash 3.2.57 (from 2007) -- so it might not be
> > up to speed when it comes to parsing the command line with odd
> > characters. (Just a theory, but I thought it would be worth pointing
> > it out.)
>
> So maybe another ls is used than the one I check? Since I have no OS X
> machine, I read the man page at
> <
> https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/ls.1.html
> >.
>
> Does your ls behaves like this? The "-w" option is important.
>
It does have the -w option, but I don't really know what to look for.
Anyway, it's hard to test as it defaults to using -w when the output isn't
a terminal.
Anyway, I've attached the output of using "ls" on some UTF-8 characters.
-- Anders
[Message part 2 (text/html, inline)]
[ls.txt (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Sun, 20 Dec 2015 15:44:01 GMT)
Full text and
rfc822 format available.
Message #65 received at 22145 <at> debbugs.gnu.org (full text, mbox):
Anders Lindgren <andlind <at> gmail.com> writes:
> Does your ls behaves like this? The "-w" option is important.
>
> It does have the -w option, but I don't really know what to look for.
> Anyway, it's hard to test as it defaults to using -w when the output
> isn't a terminal.
What does "ls --help" return?
> -- Anders
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Sun, 20 Dec 2015 17:33:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 22145 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
ls --help
ls: illegal option -- -
usage: ls [-ABCFGHLOPRSTUWabcdefghiklmnopqrstuwx1] [file ...]
-- Anders
On Sun, Dec 20, 2015 at 4:42 PM, Michael Albinus <michael.albinus <at> gmx.de>
wrote:
> Anders Lindgren <andlind <at> gmail.com> writes:
>
> > Does your ls behaves like this? The "-w" option is important.
> >
> > It does have the -w option, but I don't really know what to look for.
> > Anyway, it's hard to test as it defaults to using -w when the output
> > isn't a terminal.
>
> What does "ls --help" return?
>
> > -- Anders
>
> Best regards, Michael.
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Sun, 20 Dec 2015 17:56:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 22145 <at> debbugs.gnu.org (full text, mbox):
Anders Lindgren <andlind <at> gmail.com> writes:
> ls --help
>
> ls: illegal option -- -
>
> usage: ls [-ABCFGHLOPRSTUWabcdefghiklmnopqrstuwx1] [file ...]
Looks like it should.
Well, I've committed a patch to the emacs-25 branch, suppressing this
special test with bidi file names for OS X. Could you pls check whether
Tramp tests pass now?
> -- Anders
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Mon, 21 Dec 2015 22:36:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 22145 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi!
It no longer hangs -- thanks for excluding the problematic cases. Hopefully
you will be able to find a solution for them in the future.
Unfortunately, there are a number of normal errors reported in the tramp
test, I've attached the log.
-- Anders
On Sun, Dec 20, 2015 at 6:55 PM, Michael Albinus <michael.albinus <at> gmx.de>
wrote:
> Anders Lindgren <andlind <at> gmail.com> writes:
>
> > ls --help
> >
> > ls: illegal option -- -
> >
> > usage: ls [-ABCFGHLOPRSTUWabcdefghiklmnopqrstuwx1] [file ...]
>
> Looks like it should.
>
> Well, I've committed a patch to the emacs-25 branch, suppressing this
> special test with bidi file names for OS X. Could you pls check whether
> Tramp tests pass now?
>
> > -- Anders
>
> Best regards, Michael.
>
[Message part 2 (text/html, inline)]
[tramp-tests.log (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Tue, 22 Dec 2015 11:04:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 22145 <at> debbugs.gnu.org (full text, mbox):
Anders Lindgren <andlind <at> gmail.com> writes:
> Hi!
Hi Anders,
> It no longer hangs -- thanks for excluding the problematic cases.
> Hopefully you will be able to find a solution for them in the future.
Likely not me. I have no access to OSX machines, no chance to test.
> Unfortunately, there are a number of normal errors reported in the
> tramp test, I've attached the log.
>
> 4 unexpected results:
> FAILED tramp-test29-vc-registered
Here it seems to be a problem with the temporary bzr repository I have
created. Usually, the test case shall check whether it works
proper. I've instrumented the test case in order to see what's up.
> FAILED tramp-test32-utf8
> FAILED tramp-test32-utf8-with-ls
> FAILED tramp-test32-utf8-with-perl
That means there are problems with other strings but the arabic one,
which I have suppressed. Tests are also instrumented.
Pls let the test run again in batch mode, and send me the resulting
tramp-tests.log.
> -- Anders
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Wed, 23 Dec 2015 08:19:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 22145 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi!
Here are the new logs.
-- Anders
On Tue, Dec 22, 2015 at 12:03 PM, Michael Albinus <michael.albinus <at> gmx.de>
wrote:
> Anders Lindgren <andlind <at> gmail.com> writes:
>
> > Hi!
>
> Hi Anders,
>
> > It no longer hangs -- thanks for excluding the problematic cases.
> > Hopefully you will be able to find a solution for them in the future.
>
> Likely not me. I have no access to OSX machines, no chance to test.
>
> > Unfortunately, there are a number of normal errors reported in the
> > tramp test, I've attached the log.
> >
> > 4 unexpected results:
> > FAILED tramp-test29-vc-registered
>
> Here it seems to be a problem with the temporary bzr repository I have
> created. Usually, the test case shall check whether it works
> proper. I've instrumented the test case in order to see what's up.
>
> > FAILED tramp-test32-utf8
> > FAILED tramp-test32-utf8-with-ls
> > FAILED tramp-test32-utf8-with-perl
>
> That means there are problems with other strings but the arabic one,
> which I have suppressed. Tests are also instrumented.
>
> Pls let the test run again in batch mode, and send me the resulting
> tramp-tests.log.
>
> > -- Anders
>
> Best regards, Michael.
>
[Message part 2 (text/html, inline)]
[tramp-tests.log (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Fri, 25 Dec 2015 09:57:01 GMT)
Full text and
rfc822 format available.
Message #83 received at 22145 <at> debbugs.gnu.org (full text, mbox):
Anders Lindgren <andlind <at> gmail.com> writes:
> Hi!
Hi Anders,
> Test tramp-test29-vc-registered condition:
> (error "Running bzr init ....FAILED (status 1)")
> FAILED 30/42 tramp-test29-vc-registered
There is a problem in creating a temporary bzr repository. This is not
related to the test itself; I've committed a patch which shall make the
test more robust (not fail) in this case.
> Test tramp-test32-utf8 condition:
> (ert-test-failed
> ((should
> (equal
> (directory-files tmp-name1 nil directory-files-no-dot-files-regexp)
> (sort ... ...)))
> :form
> (equal
> (" " " " "泳櫸指列")
> (" " " " "泳櫸指列"))
> :value nil :explanation
> (list-elt 0
> (arrays-of-different-length 33 30 " " " " first-mismatch-at 3))))
> FAILED 36/42 tramp-test32-utf8
I have observed, that since my commit 0ad27a5aab529d507829c60fa79aad9866f492ab
from Dec 15, the strings are not encoded properly anymore. Could you pls
check, whether the following patch (reverting that change) solves this?
If not, pls send tramp-tests.log, again.
--8<---------------cut here---------------start------------->8---
*** ~/src/emacs-25/lisp/net/tramp-sh.el.~emacs-25~ 2015-12-25 10:52:51.759874716 +0100
--- ~/src/emacs-25/lisp/net/tramp-sh.el 2015-12-25 10:44:28.084420801 +0100
***************
*** 4218,4229 ****
(setq cs-encode (cdr cs))
(unless cs-decode (setq cs-decode 'undecided))
(unless cs-encode (setq cs-encode 'undecided))
! (setq cs-encode
! (tramp-compat-coding-system-change-eol-conversion
! cs-encode
! (if (string-match
! "^Darwin" (tramp-get-connection-property vec "uname" ""))
! 'mac 'unix)))
(tramp-send-command vec "echo foo ; echo bar" t)
(goto-char (point-min))
(when (search-forward "\r" nil t)
--- 4218,4225 ----
(setq cs-encode (cdr cs))
(unless cs-decode (setq cs-decode 'undecided))
(unless cs-encode (setq cs-encode 'undecided))
! (setq cs-encode (tramp-compat-coding-system-change-eol-conversion
! cs-encode 'unix))
(tramp-send-command vec "echo foo ; echo bar" t)
(goto-char (point-min))
(when (search-forward "\r" nil t)
--8<---------------cut here---------------end--------------->8---
> -- Anders
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Sat, 26 Dec 2015 05:02:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 22145 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi!
I just ran the tests. However, the resulting log file was too large for
"debbugs" to handle. Is there a way for me to send the file to you using
some other mechanism than mail?
-- Anders
On Fri, Dec 25, 2015 at 10:56 AM, Michael Albinus <michael.albinus <at> gmx.de>
wrote:
> Anders Lindgren <andlind <at> gmail.com> writes:
>
> > Hi!
>
> Hi Anders,
>
> > Test tramp-test29-vc-registered condition:
> > (error "Running bzr init ....FAILED (status 1)")
> > FAILED 30/42 tramp-test29-vc-registered
>
> There is a problem in creating a temporary bzr repository. This is not
> related to the test itself; I've committed a patch which shall make the
> test more robust (not fail) in this case.
>
> > Test tramp-test32-utf8 condition:
> > (ert-test-failed
> > ((should
> > (equal
> > (directory-files tmp-name1 nil directory-files-no-dot-files-regexp)
> > (sort ... ...)))
> > :form
> > (equal
> > ("套∋＜┠ � 導ｻｱｾｹ� ｼｵ ｩ＞ｿ ｣� " "栖だ≠ｾｿｾｼ ｿｾ ｳｰｻｰ⊆ずｺｵ" "捺ｳｳ讚ｸ謖㍾竜蛻�)
> > ("套�ヤｵ � 導ｻｱｾｯｱ ｼｵ 巡ｿ ｣� " "栖だ≠ｾｿｾｼ ｿｾ ｳｰｻｰ⊆ずｺｵ" "捺ｳｳ讚ｸ謖㍾竜蛻�))
> > :value nil :explanation
> > (list-elt 0
> > (arrays-of-different-length 33 30 "套∋＜┠ � 導ｻｱｾｹ� ｼｵ ｩ＞ｿ ｣�
> " "套�ヤｵ � 導ｻｱｾｯｱ ｼｵ 巡ｿ ｣� " first-mismatch-at 3))))
> > FAILED 36/42 tramp-test32-utf8
>
> I have observed, that since my commit
> 0ad27a5aab529d507829c60fa79aad9866f492ab
> from Dec 15, the strings are not encoded properly anymore. Could you pls
> check, whether the following patch (reverting that change) solves this?
> If not, pls send tramp-tests.log, again.
>
> --8<---------------cut here---------------start------------->8---
> *** ~/src/emacs-25/lisp/net/tramp-sh.el.~emacs-25~ 2015-12-25
> 10:52:51.759874716 +0100
> --- ~/src/emacs-25/lisp/net/tramp-sh.el 2015-12-25 10:44:28.084420801 +0100
> ***************
> *** 4218,4229 ****
> (setq cs-encode (cdr cs))
> (unless cs-decode (setq cs-decode 'undecided))
> (unless cs-encode (setq cs-encode 'undecided))
> ! (setq cs-encode
> ! (tramp-compat-coding-system-change-eol-conversion
> ! cs-encode
> ! (if (string-match
> ! "^Darwin" (tramp-get-connection-property vec "uname"
> ""))
> ! 'mac 'unix)))
> (tramp-send-command vec "echo foo ; echo bar" t)
> (goto-char (point-min))
> (when (search-forward "\r" nil t)
> --- 4218,4225 ----
> (setq cs-encode (cdr cs))
> (unless cs-decode (setq cs-decode 'undecided))
> (unless cs-encode (setq cs-encode 'undecided))
> ! (setq cs-encode (tramp-compat-coding-system-change-eol-conversion
> ! cs-encode 'unix))
> (tramp-send-command vec "echo foo ; echo bar" t)
> (goto-char (point-min))
> (when (search-forward "\r" nil t)
> --8<---------------cut here---------------end--------------->8---
>
> > -- Anders
>
> Best regards, Michael.
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Sat, 26 Dec 2015 19:58:02 GMT)
Full text and
rfc822 format available.
Message #89 received at 22145 <at> debbugs.gnu.org (full text, mbox):
Anders Lindgren <andlind <at> gmail.com> writes:
> Hi!
Hi Anders,
> I just ran the tests. However, the resulting log file was too large
> for "debbugs" to handle. Is there a way for me to send the file to you
> using some other mechanism than mail?
I have no place to receive large files, I don't use dropbox and
friends. Does it work to send the log file to me directly, off-list?
> -- Anders
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Sat, 26 Dec 2015 21:42:02 GMT)
Full text and
rfc822 format available.
Message #92 received at 22145 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>
> > I just ran the tests. However, the resulting log file was too large
> > for "debbugs" to handle. Is there a way for me to send the file to you
> > using some other mechanism than mail?
>
> I have no place to receive large files, I don't use dropbox and
> friends. Does it work to send the log file to me directly, off-list?
>
Yes that would work for me.
To the list: Log file sent to Micael off-list.
-- Anders
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Tue, 05 Jan 2016 21:34:02 GMT)
Full text and
rfc822 format available.
Message #95 received at 22145 <at> debbugs.gnu.org (full text, mbox):
>>>>> Michael Albinus <michael.albinus <at> gmx.de> writes:
>> It no longer hangs -- thanks for excluding the problematic cases. Hopefully
>> you will be able to find a solution for them in the future.
> Likely not me. I have no access to OSX machines, no chance to test.
"Testing tramp-tests.elc" still hangs for me on OSX, and always had. I simply
stopped running the tests in order to get emacs-25 to build.
How do I get useful information about this, since it's not even failing?
--
John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Tue, 05 Jan 2016 21:38:02 GMT)
Full text and
rfc822 format available.
Message #98 received at 22145 <at> debbugs.gnu.org (full text, mbox):
John Wiegley <jwiegley <at> gmail.com> writes:
> "Testing tramp-tests.elc" still hangs for me on OSX, and always had. I simply
> stopped running the tests in order to get emacs-25 to build.
>
> How do I get useful information about this, since it's not even failing?
Do you see in the log file, which test case hangs?
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Wed, 06 Jan 2016 00:08:01 GMT)
Full text and
rfc822 format available.
Message #101 received at 22145 <at> debbugs.gnu.org (full text, mbox):
>>>>> Michael Albinus <michael.albinus <at> gmx.de> writes:
> Do you see in the log file, which test case hangs?
I did a C-c after waiting a full hour, but tramp-tests.log is 0 bytes long.
--
John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Wed, 06 Jan 2016 04:55:01 GMT)
Full text and
rfc822 format available.
Message #104 received at 22145 <at> debbugs.gnu.org (full text, mbox):
John Wiegley <jwiegley <at> gmail.com> writes:
> I did a C-c after waiting a full hour, but tramp-tests.log is 0 bytes long.
What happens, if you call
# make -C test/automated tramp-tests
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Wed, 06 Jan 2016 18:40:02 GMT)
Full text and
rfc822 format available.
Message #107 received at 22145 <at> debbugs.gnu.org (full text, mbox):
>>>>> Michael Albinus <michael.albinus <at> gmx.de> writes:
> What happens, if you call
> # make -C test/automated tramp-tests
Pretty much identical behavior, except that it didn't even attempt to write a
zero byte log file:
--8<---------------cut here---------------start------------->8---
[nix-shell:~/.emacs.d/devel]$ make -C test/automated tramp-tests
make: Entering directory '/Users/johnw/Projects/dot-emacs/devel/test/automated'
make[1]: Entering directory '/Users/johnw/Projects/dot-emacs/devel/test/automated'
make[2]: Entering directory '/Users/johnw/Projects/dot-emacs/devel/test/automated'
make[2]: 'tramp-tests.elc' is up to date.
make[2]: Leaving directory '/Users/johnw/Projects/dot-emacs/devel/test/automated'
Testing tramp-tests.elc
^CMakefile:94: recipe for target 'tramp-tests.log' failed
make[1]: *** [tramp-tests.log] Error 2
Makefile:122: recipe for target 'tramp-tests' failed
make: *** [tramp-tests] Interrupt: 2
--8<---------------cut here---------------end--------------->8---
There is no tramp-tests.log after waiting a while and pressing C-c.
--
John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Wed, 06 Jan 2016 18:49:01 GMT)
Full text and
rfc822 format available.
Message #110 received at 22145 <at> debbugs.gnu.org (full text, mbox):
> From: John Wiegley <jwiegley <at> gmail.com>
> Date: Wed, 06 Jan 2016 10:39:35 -0800
> Cc: 22145 <at> debbugs.gnu.org, Anders Lindgren <andlind <at> gmail.com>
>
> >>>>> Michael Albinus <michael.albinus <at> gmx.de> writes:
>
> > What happens, if you call
> > # make -C test/automated tramp-tests
>
> Pretty much identical behavior, except that it didn't even attempt to write a
> zero byte log file:
If you attach a debugger to emacs while it hangs, where do you find it
lurking?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Wed, 06 Jan 2016 19:05:02 GMT)
Full text and
rfc822 format available.
Message #113 received at 22145 <at> debbugs.gnu.org (full text, mbox):
>>>>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> Pretty much identical behavior, except that it didn't even attempt to write a
>> zero byte log file:
> If you attach a debugger to emacs while it hangs, where do you find it
> lurking?
Oh hey, weird, this time it actually ran to completion:
Ran 42 tests, 37 results as expected, 3 unexpected, 2 skipped (2016-01-06 19:03:56+0000)
2 expected failures
3 unexpected results:
FAILED tramp-test32-utf8
FAILED tramp-test32-utf8-with-ls
FAILED tramp-test32-utf8-with-perl
2 skipped results:
SKIPPED tramp-test31-special-characters-with-stat
SKIPPED tramp-test32-utf8-with-stat
Looks like I'll have to try a bit harder to find out why it's hanging
sometimes. When that does happen, I'll attach to the process as you suggest,
Eli.
--
John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Thu, 07 Jan 2016 20:04:01 GMT)
Full text and
rfc822 format available.
Message #116 received at 22145 <at> debbugs.gnu.org (full text, mbox):
John Wiegley <jwiegley <at> gmail.com> writes:
> 3 unexpected results:
> FAILED tramp-test32-utf8
> FAILED tramp-test32-utf8-with-ls
> FAILED tramp-test32-utf8-with-perl
Well, I'm desperate with this. It fails only for OS X. The latest traces
from Anders didn't give me a new idea how to fix :-(
Since I have no chance to test on OS X, I'm thinking about to skip those
tests there. Not that I like it.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Thu, 07 Jan 2016 20:32:02 GMT)
Full text and
rfc822 format available.
Message #119 received at 22145 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>
> Since I have no chance to test on OS X, I'm thinking about to skip those
> tests there. Not that I like it.
>
Over the past few weeks I've been involved with several bugs that only
occurs on OS X.
Wouldn't it be possible for FSF, or the Emacs project itself, to provide an
OS X machine that could be used by developers in similar situations. The
machine could double as an automated test server.
-- Anders
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Thu, 07 Jan 2016 23:35:02 GMT)
Full text and
rfc822 format available.
Message #122 received at 22145 <at> debbugs.gnu.org (full text, mbox):
>>>>> Michael Albinus <michael.albinus <at> gmx.de> writes:
> John Wiegley <jwiegley <at> gmail.com> writes:
>> 3 unexpected results:
>> FAILED tramp-test32-utf8
>> FAILED tramp-test32-utf8-with-ls
>> FAILED tramp-test32-utf8-with-perl
> Well, I'm desperate with this. It fails only for OS X. The latest traces
> from Anders didn't give me a new idea how to fix :-(
> Since I have no chance to test on OS X, I'm thinking about to skip those
> tests there. Not that I like it.
I'd prefer to skip them, and open a bug whose resolution should include
unskipping them. That way, they aren't blocking "make check" for everyone
who's waiting on this bug to be fixed.
--
John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Fri, 08 Jan 2016 03:12:01 GMT)
Full text and
rfc822 format available.
Message #125 received at submit <at> debbugs.gnu.org (full text, mbox):
Michael Albinus <michael.albinus <at> gmx.de> writes:
> John Wiegley <jwiegley <at> gmail.com> writes:
>
>> 3 unexpected results:
>> FAILED tramp-test32-utf8
>> FAILED tramp-test32-utf8-with-ls
>> FAILED tramp-test32-utf8-with-perl
>
> Well, I'm desperate with this. It fails only for OS X. The latest traces
> from Anders didn't give me a new idea how to fix :-(
What exactly are the tests? How does Tramp make use of the file system
encoding, if it does at all?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Fri, 08 Jan 2016 03:19:02 GMT)
Full text and
rfc822 format available.
Message #128 received at submit <at> debbugs.gnu.org (full text, mbox):
Anders Lindgren <andlind <at> gmail.com> writes:
> Over the past few weeks I've been involved with several bugs that only
> occurs on OS X.
>
> Wouldn't it be possible for FSF, or the Emacs project itself, to
> provide an OS X machine that could be used by developers in similar
> situations. The machine could double as an automated test server.
I suspect the fact that OSX is a non-free OS would likely be an obstacle
to that. It might be more realistic to talk about a GNU-Darwin/GNUStep
box, but that doesn't necessarily change the fact that the purpose of
such a machine would be to improve Emacs for users of a non-free OS.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Fri, 08 Jan 2016 06:04:02 GMT)
Full text and
rfc822 format available.
Message #131 received at 22145 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> Wouldn't it be possible for FSF, or the Emacs project itself, to provide an
> OS X machine that could be used by developers in similar situations.
Our goal is to our goal is to eliminate MacOS, not to enhance it.
A nonfree program tramples the freedom of those who use it.
If we were running MacOS on a computer, it would take away
our freedom. Of course, we don't do that.
If we suggested that others run MacOS, we would be inviting them to
surrender their freedom. We would be doing wrong to them, and
legitimizing that nonfree software as a byproduct. Of course, we
don't do that.
See http://gnu.org/philosophy/free-software-even-more-important.html
for why nonfree software is an injustice.
See http://gnu.org/philosophy/is-ever-good-use-nonfree-program.html
for the very narrow circumstances in which it is good to use a nonfree
program: for putting an end to its use. We don't need to develop
a free replacement for MacOS because we already have one:
the GNU/Linux system.
See https://trisquel.info/en/wiki/macbook for how to install one
of the free GNU/Linux distros on a Mac.
--
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Fri, 08 Jan 2016 09:02:02 GMT)
Full text and
rfc822 format available.
Message #134 received at 22145 <at> debbugs.gnu.org (full text, mbox):
Random832 <random832 <at> fastmail.com> writes:
>>> 3 unexpected results:
>>> FAILED tramp-test32-utf8
>>> FAILED tramp-test32-utf8-with-ls
>>> FAILED tramp-test32-utf8-with-perl
>>
>> Well, I'm desperate with this. It fails only for OS X. The latest traces
>> from Anders didn't give me a new idea how to fix :-(
>
> What exactly are the tests? How does Tramp make use of the file system
> encoding, if it does at all?
Tramp does nothing special on file encoding, it simply sets LC_ALL to
something utf8 related on the remote machine, and it uses shell
commands like ls and friends, or perl. Works everywhere but on OSX.
The test cases manipulate the file names "Γυρίστε το Γαλαξία με Ώτο Στοπ",
"أصبح بوسعك الآن تنزيل نسخة كاملة من موسوعة ويكيبيديا العربية لتصفحها بلا اتصال بالإنترنت",
"银河系漫游指南系列" and "Автостопом по гала́ктике" on the remote machine
and check, whether everything works as expected.
Likely, I could test it without running Emacs on an OSX machine. If
somebody could give me temporarily a very restricted account on an OSX
machine, I could use "/ssh:restrictedaccount <at> osx-machine:/tmp" as test
target. If the problem is reproducibly with this, I could debug Tramp,
running on my local machine.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Fri, 08 Jan 2016 09:14:01 GMT)
Full text and
rfc822 format available.
Message #137 received at 22145 <at> debbugs.gnu.org (full text, mbox):
John Wiegley <jwiegley <at> gmail.com> writes:
> I'd prefer to skip them, and open a bug whose resolution should include
> unskipping them. That way, they aren't blocking "make check" for everyone
> who's waiting on this bug to be fixed.
As the very last resort I've disabled the Chinese file name test for
OSX. Anders, does it work for you?
If not, I'll go the way John has proposed.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Fri, 08 Jan 2016 13:40:02 GMT)
Full text and
rfc822 format available.
Message #140 received at 22145 <at> debbugs.gnu.org (full text, mbox):
On Fri, Jan 8, 2016, at 04:01, Michael Albinus wrote:
> The test cases manipulate the file names "Γυρίστε το Γαλαξία με Ώτο
> Στοπ",
> "أصبح بوسعك الآن تنزيل نسخة كاملة من موسوعة ويكيبيديا العربية لتصفحها بلا
> اتصال بالإنترنت",
> "银河系漫游指南系列" and "Автостопом по гала́ктике" on the remote machine
> and check, whether everything works as expected.
If I were to guess that the Chinese name works fine and the Greek and
Cyrillic ones do not (don't know enough about the script to make an
immediate guess about the Arabic), would I be right? Or can the test
failure not give you that information?
Have you been following the discussions last month about the issues with
file name completion for local OSX filenames?
The issue is most likely that filenames on OSX are (in most
circumstances) normalized to turn diacritics into combining characters.
This is undone, on OSX machines, by using the utf-8-hfs (formerly
utf-8-nfd, which was incomplete and may or may not have worked for your
purpose, but the patch for last month's bug replaces it with an alias
for utf-8-hfs) encoding.
> Likely, I could test it without running Emacs on an OSX machine. If
> somebody could give me temporarily a very restricted account on an OSX
> machine, I could use "/ssh:restrictedaccount <at> osx-machine:/tmp" as test
> target. If the problem is reproducibly with this, I could debug Tramp,
> running on my local machine.
I'll see what I can do this weekend.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Fri, 08 Jan 2016 14:18:02 GMT)
Full text and
rfc822 format available.
Message #143 received at 22145 <at> debbugs.gnu.org (full text, mbox):
Random832 <random832 <at> fastmail.com> writes:
Hi,
> If I were to guess that the Chinese name works fine and the Greek and
> Cyrillic ones do not (don't know enough about the script to make an
> immediate guess about the Arabic), would I be right? Or can the test
> failure not give you that information?
The Arabic name let's the test freeze forever; it is sklipped for OSX
already. From the other names, my first candidate for producing the
problem is the Chinese name. I've suppressed it as well earlier today,
let's see the feedback from Anders or somebody else.
> Have you been following the discussions last month about the issues with
> file name completion for local OSX filenames?
Yes.
> The issue is most likely that filenames on OSX are (in most
> circumstances) normalized to turn diacritics into combining characters.
> This is undone, on OSX machines, by using the utf-8-hfs (formerly
> utf-8-nfd, which was incomplete and may or may not have worked for your
> purpose, but the patch for last month's bug replaces it with an alias
> for utf-8-hfs) encoding.
But IIUC correctly, this touches only local file names and how they are
handled in Emacs. Tramp works on the remote side.
Anyway, this is exactly something I'd like to debug.
>> Likely, I could test it without running Emacs on an OSX machine. If
>> somebody could give me temporarily a very restricted account on an OSX
>> machine, I could use "/ssh:restrictedaccount <at> osx-machine:/tmp" as test
>> target. If the problem is reproducibly with this, I could debug Tramp,
>> running on my local machine.
>
> I'll see what I can do this weekend.
That would be great!
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Fri, 08 Jan 2016 17:41:02 GMT)
Full text and
rfc822 format available.
Message #146 received at 22145 <at> debbugs.gnu.org (full text, mbox):
On Fri, Jan 8, 2016, at 09:17, Michael Albinus wrote:
> But IIUC correctly, this touches only local file names and how they are
> handled in Emacs. Tramp works on the remote side.
The point is, the filenames (the remote filenames if the remote is OSX)
will have the decomposed characters, and therefore may not match if the
tests are expecting ls to come back with the composed ones. Tramp may
need to get some way to specify a filesystem encoding for the remote
host even where that may differ from the local filesystem.
If you're getting issues with the Chinese name, though, this probably
isn't the issue (or at least isn't the only issue).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Fri, 08 Jan 2016 18:48:02 GMT)
Full text and
rfc822 format available.
Message #149 received at 22145 <at> debbugs.gnu.org (full text, mbox):
Random832 <random832 <at> fastmail.com> writes:
> The point is, the filenames (the remote filenames if the remote is OSX)
> will have the decomposed characters, and therefore may not match if the
> tests are expecting ls to come back with the composed ones. Tramp may
> need to get some way to specify a filesystem encoding for the remote
> host even where that may differ from the local filesystem.
Tramp sets utf-8-mac for encoding and utf-8 for decoding. I'll play with
utf-8-hfs when testing on a OSX machine.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Fri, 08 Jan 2016 20:15:01 GMT)
Full text and
rfc822 format available.
Message #152 received at 22145 <at> debbugs.gnu.org (full text, mbox):
On Fri, Jan 8, 2016, at 13:47, Michael Albinus wrote:
> Tramp sets utf-8-mac for encoding and utf-8 for decoding. I'll play with
> utf-8-hfs when testing on a OSX machine.
utf-8-hfs is part of ucs-normalize and IIRC works on all platforms.
utf-8-nfd is the old one which only existed on the ns implementation,
and didn't work for encoding anyway (which was the cause of the
completion bug).
AIUI utf-8-mac is regular UTF-8 with CR line endings and is intended for
use with files created on *classic* MacOS, and should not be used for
this purpose.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Sat, 09 Jan 2016 13:02:02 GMT)
Full text and
rfc822 format available.
Message #155 received at 22145 <at> debbugs.gnu.org (full text, mbox):
Random832 <random832 <at> fastmail.com> writes:
> utf-8-hfs is part of ucs-normalize and IIRC works on all platforms.
Yes, setting the coding system to utf-8-hfs let pass Tramp tests on OS
X. Except for the R2L Arabic string, but I can live with this. This test
is skipped on OS X.
Could somebody (Anders?) confirm, that Tramp tests run proper on OS X?
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Sat, 09 Jan 2016 13:07:01 GMT)
Full text and
rfc822 format available.
Message #158 received at 22145 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Date: Sat, 09 Jan 2016 14:00:54 +0100
> Cc: 22145 <at> debbugs.gnu.org
>
> Yes, setting the coding system to utf-8-hfs let pass Tramp tests on OS
> X. Except for the R2L Arabic string, but I can live with this.
Do you understand why the Arabic string fails? Bidirectional scripts
have nothing to do with file names: file names are always stored in
strict logical order of the characters.
Can you show 2 strings that fail the test, and tell why they fail it
(i.e. which test fails to match the ert predicate)? Maybe I can then
tell how to fix that for OS X.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Sat, 09 Jan 2016 19:16:01 GMT)
Full text and
rfc822 format available.
Message #161 received at 22145 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Do you understand why the Arabic string fails? Bidirectional scripts
> have nothing to do with file names: file names are always stored in
> strict logical order of the characters.
>
> Can you show 2 strings that fail the test, and tell why they fail it
> (i.e. which test fails to match the ert predicate)? Maybe I can then
> tell how to fix that for OS X.
I will check whether I could use the OS X machine for further tests.
> Thanks.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Sat, 09 Jan 2016 19:25:01 GMT)
Full text and
rfc822 format available.
Message #164 received at 22145 <at> debbugs.gnu.org (full text, mbox):
On Sat, Jan 9, 2016, at 08:06, Eli Zaretskii wrote:
> Do you understand why the Arabic string fails?
Just to immediately rule out one possibility, the string does appear at
least in my own ad-hoc tests to encode correctly to the same name that
gets created if the string is used as-is to create a file, and
round-trip correctly to the original string, with the utf-8-hfs
encoding.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Sat, 09 Jan 2016 20:19:02 GMT)
Full text and
rfc822 format available.
Message #167 received at 22145 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Do you understand why the Arabic string fails? Bidirectional scripts
> have nothing to do with file names: file names are always stored in
> strict logical order of the characters.
>
> Can you show 2 strings that fail the test, and tell why they fail it
> (i.e. which test fails to match the ert predicate)? Maybe I can then
> tell how to fix that for OS X.
No ert predicate fails. Tramp simply hangs.
The following command works as expected:
--8<---------------cut here---------------start------------->8---
# (test -e /Users/test1/tmp/tramp-test8687J1V/\أ\ص\ب\ح\ \ب\و\س\ع\ك\ \ا\ل\آ\ن\ \ت\ن\ز\ي\ل\ \ن\س\خ\ة\ \ك\ا\م\ل\ة\ \م\ن\ \م\و\س\و\ع\ة\ \و\ي\ك\ي\ب\ي\د\ي\ا\ \ا\ل\ع\ر\ب\ي\ة\ \ل\ت\ص\ف\ح\ه\ا\ \ب\ل\ا\ \ا\ت\ص\ا\ل\ \ب\ا\ل\إ\ن\ت\ر\ن\ت || test -h /Users/test1/tmp/tramp-test8687J1V/\أ\ص\ب\ح\ \ب\و\س\ع\ك\ \ا\ل\آ\ن\ \ت\ن\ز\ي\ل\ \ن\س\خ\ة\ \ك\ا\م\ل\ة\ \م\ن\ \م\و\س\و\ع\ة\ \و\ي\ك\ي\ب\ي\د\ي\ا\ \ا\ل\ع\ر\ب\ي\ة\ \ل\ت\ص\ف\ح\ه\ا\ \ب\ل\ا\ \ا\ت\ص\ا\ل\ \ب\ا\ل\إ\ن\ت\ر\ن\ت) && /bin/ls -ildn -w /Users/test1/tmp/tramp-test8687J1V/\أ\ص\ب\ح\ \ب\و\س\ع\ك\ \ا\ل\آ\ن\ \ت\ن\ز\ي\ل\ \ن\س\خ\ة\ \ك\ا\م\ل\ة\ \م\ن\ \م\و\س\و\ع\ة\ \و\ي\ك\ي\ب\ي\د\ي\ا\ \ا\ل\ع\ر\ب\ي\ة\ \ل\ت\ص\ف\ح\ه\ا\ \ب\ل\ا\ \ا\ت\ص\ا\ل\ \ب\ا\ل\إ\ن\ت\ر\ن\ت
--8<---------------cut here---------------end--------------->8---
And this command hangs and does not return:
--8<---------------cut here---------------start------------->8---
# (test -e /Users/test1/tmp/tramp-test8687J1V/foo/\أ\ص\ب\ح\ \ب\و\س\ع\ك\ \ا\ل\آ\ن\ \ت\ن\ز\ي\ل\ \ن\س\خ\ة\ \ك\ا\م\ل\ة\ \م\ن\ \م\و\س\و\ع\ة\ \و\ي\ك\ي\ب\ي\د\ي\ا\ \ا\ل\ع\ر\ب\ي\ة\ \ل\ت\ص\ف\ح\ه\ا\ \ب\ل\ا\ \ا\ت\ص\ا\ل\ \ب\ا\ل\إ\ن\ت\ر\ن\ت/\أ\ص\ب\ح\ \ب\و\س\ع\ك\ \ا\ل\آ\ن\ \ت\ن\ز\ي\ل\ \ن\س\خ\ة\ \ك\ا\م\ل\ة\ \م\ن\ \م\و\س\و\ع\ة\ \و\ي\ك\ي\ب\ي\د\ي\ا\ \ا\ل\ع\ر\ب\ي\ة\ \ل\ت\ص\ف\ح\ه\ا\ \ب\ل\ا\ \ا\ت\ص\ا\ل\ \ب\ا\ل\إ\ن\ت\ر\ن\ت || test -h /Users/test1/tmp/tramp-test8687J1V/foo/\أ\ص\ب\ح\ \ب\و\س\ع\ك\ \ا\ل\آ\ن\ \ت\ن\ز\ي\ل\ \ن\س\خ\ة\ \ك\ا\م\ل\ة\ \م\ن\ \م\و\س\و\ع\ة\ \و\ي\ك\ي\ب\ي\د\ي\ا\ \ا\ل\ع\ر\ب\ي\ة\ \ل\ت\ص\ف\ح\ه\ا\ \ب\ل\ا\ \ا\ت\ص\ا\ل\ \ب\ا\ل\إ\ن\ت\ر\ن\ت/\أ\ص\ب\ح\ \ب\و\س\ع\ك\ \ا\ل\آ\ن\ \ت\ن\ز\ي\ل\ \ن\س\خ\ة\ \ك\ا\م\ل\ة\ \م\ن\ \م\و\س\و\ع\ة\ \و\ي\ك\ي\ب\ي\د\ي\ا\ \ا\ل\ع\ر\ب\ي\ة\ \ل\ت\ص\ف\ح\ه\ا\ \ب\ل\ا\ \ا\ت\ص\ا\ل\ \ب\ا\ل\إ\ن\ت\ر\ن\ت) && /bin/ls -ildn -w /Users/test1/tmp/tramp-test8687J1V/foo/\أ\ص\ب\ح\ \ب\و\س\ع\ك\ \ا\ل\آ\ن\ \ت\ن\ز\ي\ل\ \ن\س\خ\ة\ \ك\ا\م\ل\ة\ \م\ن\ \م\و\س\و\ع\ة\ \و\ي\ك\ي\ب\ي\د\ي\ا\ \ا\ل\ع\ر\ب\ي\ة\ \ل\ت\ص\ف\ح\ه\ا\ \ب\ل\ا\ \ا\ت\ص\ا\ل\ \ب\ا\ل\إ\ن\ت\ر\ن\ت/\أ\ص\ب\ح\ \ب\و\س\ع\ك\ \ا\ل\آ\ن\ \ت\ن\ز\ي\ل\ \ن\س\خ\ة\ \ك\ا\م\ل\ة\ \م\ن\ \م\و\س\و\ع\ة\ \و\ي\ك\ي\ب\ي\د\ي\ا\ \ا\ل\ع\ر\ب\ي\ة\ \ل\ت\ص\ف\ح\ه\ا\ \ب\ل\ا\ \ا\ت\ص\ا\ل\ \ب\ا\ل\إ\ن\ت\ر\ن\ت
--8<---------------cut here---------------end--------------->8---
Maybe the command is simply too long for the shell?
> Thanks.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Sat, 09 Jan 2016 20:27:01 GMT)
Full text and
rfc822 format available.
Message #170 received at 22145 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: random832 <at> fastmail.com, 22145 <at> debbugs.gnu.org
> Date: Sat, 09 Jan 2016 21:18:04 +0100
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Do you understand why the Arabic string fails? Bidirectional scripts
> > have nothing to do with file names: file names are always stored in
> > strict logical order of the characters.
> >
> > Can you show 2 strings that fail the test, and tell why they fail it
> > (i.e. which test fails to match the ert predicate)? Maybe I can then
> > tell how to fix that for OS X.
>
> No ert predicate fails. Tramp simply hangs.
Hangs before or after receiving the response from the remote?
> The following command works as expected:
>
> --8<---------------cut here---------------start------------->8---
> # (test -e /Users/test1/tmp/tramp-test8687J1V/\أ\ص\ب\ح\ \ب\و\س\ع\ك\ \ا\ل\آ\ن\ \ت\ن\ز\ي\ل\ \ن\س\خ\ة\ \ك\ا\م\ل\ة\ \م\ن\ \م\و\س\و\ع\ة\ \و\ي\ك\ي\ب\ي\د\ي\ا\ \ا\ل\ع\ر\ب\ي\ة\ \ل\ت\ص\ف\ح\ه\ا\ \ب\ل\ا\ \ا\ت\ص\ا\ل\ \ب\ا\ل\إ\ن\ت\ر\ن\ت || test -h /Users/test1/tmp/tramp-test8687J1V/\أ\ص\ب\ح\ \ب\و\س\ع\ك\ \ا\ل\آ\ن\ \ت\ن\ز\ي\ل\ \ن\س\خ\ة\ \ك\ا\م\ل\ة\ \م\ن\ \م\و\س\و\ع\ة\ \و\ي\ك\ي\ب\ي\د\ي\ا\ \ا\ل\ع\ر\ب\ي\ة\ \ل\ت\ص\ف\ح\ه\ا\ \ب\ل\ا\ \ا\ت\ص\ا\ل\ \ب\ا\ل\إ\ن\ت\ر\ن\ت) && /bin/ls -ildn -w /Users/test1/tmp/tramp-test8687J1V/\أ\ص\ب\ح\ \ب\و\س\ع\ك\ \ا\ل\آ\ن\ \ت\ن\ز\ي\ل\ \ن\س\خ\ة\ \ك\ا\م\ل\ة\ \م\ن\ \م\و\س\و\ع\ة\ \و\ي\ك\ي\ب\ي\د\ي\ا\ \ا\ل\ع\ر\ب\ي\ة\ \ل\ت\ص\ف\ح\ه\ا\ \ب\ل\ا\ \ا\ت\ص\ا\ل\ \ب\ا\ل\إ\ن\ت\ر\ن\ت
> --8<---------------cut here---------------end--------------->8---
>
> And this command hangs and does not return:
>
> --8<---------------cut here---------------start------------->8---
> # (test -e /Users/test1/tmp/tramp-test8687J1V/foo/\أ\ص\ب\ح\ \ب\و\س\ع\ك\ \ا\ل\آ\ن\ \ت\ن\ز\ي\ل\ \ن\س\خ\ة\ \ك\ا\م\ل\ة\ \م\ن\ \م\و\س\و\ع\ة\ \و\ي\ك\ي\ب\ي\د\ي\ا\ \ا\ل\ع\ر\ب\ي\ة\ \ل\ت\ص\ف\ح\ه\ا\ \ب\ل\ا\ \ا\ت\ص\ا\ل\ \ب\ا\ل\إ\ن\ت\ر\ن\ت/\أ\ص\ب\ح\ \ب\و\س\ع\ك\ \ا\ل\آ\ن\ \ت\ن\ز\ي\ل\ \ن\س\خ\ة\ \ك\ا\م\ل\ة\ \م\ن\ \م\و\س\و\ع\ة\ \و\ي\ك\ي\ب\ي\د\ي\ا\ \ا\ل\ع\ر\ب\ي\ة\ \ل\ت\ص\ف\ح\ه\ا\ \ب\ل\ا\ \ا\ت\ص\ا\ل\ \ب\ا\ل\إ\ن\ت\ر\ن\ت || test -h /Users/test1/tmp/tramp-test8687J1V/foo/\أ\ص\ب\ح\ \ب\و\س\ع\ك\ \ا\ل\آ\ن\ \ت\ن\ز\ي\ل\ \ن\س\خ\ة\ \ك\ا\م\ل\ة\ \م\ن\ \م\و\س\و\ع\ة\ \و\ي\ك\ي\ب\ي\د\ي\ا\ \ا\ل\ع\ر\ب\ي\ة\ \ل\ت\ص\ف\ح\ه\ا\ \ب\ل\ا\ \ا\ت\ص\ا\ل\ \ب\ا\ل\إ\ن\ت\ر\ن\ت/\أ\ص\ب\ح\ \ب\و\س\ع\ك\ \ا\ل\آ\ن\ \ت\ن\ز\ي\ل\ \ن\س\خ\ة\ \ك\ا\م\ل\ة\ \م\ن\ \م\و\س\و\ع\ة\ \و\ي\ك\ي\ب\ي\د\ي\ا\ \ا\ل\ع\ر\ب\ي\ة\ \ل\ت\ص\ف\ح\ه\ا\ \ب\ل\ا\ \ا\ت\ص\ا\ل\ \ب\ا\ل\إ\ن\ت\ر\ن\ت) && /bin/ls -ildn -w /Users/test1/tmp/tramp-test8687J1V/foo/\أ\ص\ب\ح\ \ب\و\س\ع\ك\ \ا\ل\آ\ن\ \ت\ن\ز\ي\ل\ \ن\س\خ\ة\ \ك\ا\م\ل\ة\ \م\ن\ \م\و\س\و\ع\ة\ \و\ي\ك\ي\ب\ي\د\ي\ا\ \ا\ل\ع\ر\ب\ي\ة\ \ل\ت\ص\ف\ح\ه\ا\ \ب\ل\ا\ \ا\ت\ص\ا\ل\ \ب\ا\ل\إ\ن\ت\ر\ن\ت/\أ\ص\ب\ح\ \ب\و\س\ع\ك\ \ا\ل\آ\ن\ \ت\ن\ز\ي\ل\ \ن\س\خ\ة\ \ك\ا\م\ل\ة\ \م\ن\ \م\و\س\و\ع\ة\ \و\ي\ك\ي\ب\ي\د\ي\ا\ \ا\ل\ع\ر\ب\ي\ة\ \ل\ت\ص\ف\ح\ه\ا\ \ب\ل\ا\ \ا\ت\ص\ا\ل\ \ب\ا\ل\إ\ن\ت\ر\ن\ت
> --8<---------------cut here---------------end--------------->8---
>
> Maybe the command is simply too long for the shell?
It's just 1.6K, hardly long enough for that, I think.
Maybe you should just use the shorter command, it's good enough for
what you wanted to test here, right?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Sun, 10 Jan 2016 08:50:01 GMT)
Full text and
rfc822 format available.
Message #173 received at 22145 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> No ert predicate fails. Tramp simply hangs.
>
> Hangs before or after receiving the response from the remote?
Null response from the remote.
>> Maybe the command is simply too long for the shell?
>
> It's just 1.6K, hardly long enough for that, I think.
There are small limits on OS X:
# getconf PATH_MAX ~/
1024
On my GNU/Linux system, there is for example:
# getconf PATH_MAX ~/
4096
> Maybe you should just use the shorter command, it's good enough for
> what you wanted to test here, right?
This are two different commands for different purposes, raised by Tramp
from the test case. I wanted to show, that the R2L property of the path
name does not seem to be the problem.
I'll try to rearrange the shell commands, let's see whether it
works. Fortunately, I can test on the remote OS X machine, again.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Sun, 10 Jan 2016 12:51:01 GMT)
Full text and
rfc822 format available.
Message #176 received at 22145 <at> debbugs.gnu.org (full text, mbox):
Michael Albinus <michael.albinus <at> gmx.de> writes:
> I'll try to rearrange the shell commands, let's see whether it
> works. Fortunately, I can test on the remote OS X machine, again.
Done. Everything works fine now, so I could also reenable the Arabic
file name for test.
If somebody could acknowledge that tramp-test.el perform proper on OS X,
I'll close the bug.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Tue, 12 Jan 2016 16:25:01 GMT)
Full text and
rfc822 format available.
Message #179 received at 22145 <at> debbugs.gnu.org (full text, mbox):
>>>>> Michael Albinus <michael.albinus <at> gmx.de> writes:
> Could somebody (Anders?) confirm, that Tramp tests run proper on OS X?
tramp-tests.el still hangs on my Mac (I let it run overnight). I'm rebuilding
now to attempt to isolate further.
Can we disable these tests until this bug is resolved? It causes me to be
unable to run the tests when building Nix packages, since it never completes.
--
John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Tue, 12 Jan 2016 17:05:02 GMT)
Full text and
rfc822 format available.
Message #182 received at 22145 <at> debbugs.gnu.org (full text, mbox):
>>>>> Michael Albinus <michael.albinus <at> gmx.de> writes:
> Could somebody (Anders?) confirm, that Tramp tests run proper on OS X?
I can't get tramp tests to run with "make -C test/automated tramp-tests", and
they don't produce a log file. Next I'll try evaluating them within Emacs.
--
John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Tue, 12 Jan 2016 19:07:01 GMT)
Full text and
rfc822 format available.
Message #185 received at 22145 <at> debbugs.gnu.org (full text, mbox):
John Wiegley <jwiegley <at> gmail.com> writes:
> I can't get tramp tests to run with "make -C test/automated tramp-tests", and
> they don't produce a log file. Next I'll try evaluating them within Emacs.
OK. I'm waiting for your feedback, before I change something.
Best regards, Michael.
bug marked as fixed in version 25.1, send any further explanations to
22145 <at> debbugs.gnu.org and Anders Lindgren <andlind <at> gmail.com>
Request was from
Michael Albinus <michael.albinus <at> gmx.de>
to
control <at> debbugs.gnu.org.
(Sat, 16 Jan 2016 09:41: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.
(Sat, 13 Feb 2016 12:24:04 GMT)
Full text and
rfc822 format available.
bug unarchived.
Request was from
Michael Albinus <michael.albinus <at> gmx.de>
to
control <at> debbugs.gnu.org.
(Thu, 17 Mar 2016 19:38:02 GMT)
Full text and
rfc822 format available.
bug No longer marked as fixed in versions 25.1 and reopened.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Thu, 17 Mar 2016 19:39:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Thu, 17 Mar 2016 19:40:02 GMT)
Full text and
rfc822 format available.
Message #196 received at 22145 <at> debbugs.gnu.org (full text, mbox):
John Wiegley <jwiegley <at> gmail.com> writes:
> Hi Michael,
Hi John,
> tramp-tests.elc still hangs indefinitely on Mac.
>
> Can you please disable that test for 25.1 until it is fixed? I would really
> like to be able to run all tests using "make check" here on my machine.
Done. I've also reopened Bug#22145.
But I have *no* chance to test and fix it on OSX. Could somebody grant
me access to such a machine, that I could test it in master?
> Thanks,
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Mon, 21 Mar 2016 21:09:01 GMT)
Full text and
rfc822 format available.
Message #199 received at 22145 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>>>>> Michael Albinus <michael.albinus <at> gmx.de> writes:
>> Can you please disable that test for 25.1 until it is fixed? I would really
>> like to be able to run all tests using "make check" here on my machine.
> Done. I've also reopened Bug#22145.
Hi Michael,
I've pulled in emacs-25 and rebuilt, but it's still running "tramp-tests.elc",
and still hanging on them.
Is there something else I should be doing?
> But I have *no* chance to test and fix it on OSX. Could somebody grant me
> access to such a machine, that I could test it in master?
I could give you such access, can you please send me your SSH public key
(preferably GPG-signed)?
--
John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Tue, 22 Mar 2016 10:10:01 GMT)
Full text and
rfc822 format available.
Message #202 received at 22145 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
John Wiegley <jwiegley <at> gmail.com> writes:
> Hi Michael,
Hi John,
> I've pulled in emacs-25 and rebuilt, but it's still running "tramp-tests.elc",
> and still hanging on them.
>
> Is there something else I should be doing?
We could increase debug level. But it might be more easy I'll debug myself.
>> But I have *no* chance to test and fix it on OSX. Could somebody grant me
>> access to such a machine, that I could test it in master?
>
> I could give you such access, can you please send me your SSH public key
> (preferably GPG-signed)?
My RSA and DSA keys are appended. This week, my daughter and my grandson
are visiting us, there isn't too much time left for hacking ...
I would investigate next week. Just tell me, when it is OK for you.
Best regards, Michael.
[id_rsa.pub (application/octet-stream, attachment)]
[id_dsa.pub (application/octet-stream, attachment)]
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Fri, 01 Apr 2016 08:37:01 GMT)
Full text and
rfc822 format available.
Message #205 received at 22145 <at> debbugs.gnu.org (full text, mbox):
Michael Albinus <michael.albinus <at> gmx.de> writes:
Hi John,
[I have performed tests on John's machine]
> If I [...] call 'make -C test/automated check', Tramp tests pass. See
> tramp-tests.log.
>
> Strange. It looks, like the NIX environment makes it block. I remember,
> when bringing tramp-tests.el to hydra, there were also problems. I even
> added some code to detect whether the tests run in a NIX environment,
> see tramp-tests.el lines 78-80.
Given, that the last problems related to OS X have been solved by commit
df441b362c25c4ad59ea3d83137328d0d4098eaf, I believe we could close this
bug. Do you agree?
Of course, I'm still working on the problems with your local NIX
environment and the Tramp tests. But this is another story.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22145; Package
emacs.
(Sat, 02 Apr 2016 21:47:03 GMT)
Full text and
rfc822 format available.
Message #208 received at 22145 <at> debbugs.gnu.org (full text, mbox):
>>>>> Michael Albinus <michael.albinus <at> gmx.de> writes:
> Given, that the last problems related to OS X have been solved by commit
> df441b362c25c4ad59ea3d83137328d0d4098eaf, I believe we could close this bug.
> Do you agree?
OK, if you think this is a Nix bug and not an Emacs bug, then I'll take
responsibility from here for the Nix fix and you can close this issue.
Thanks for helping me debug this!
--
John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2
Reply sent
to
Michael Albinus <michael.albinus <at> gmx.de>:
You have taken responsibility.
(Sun, 03 Apr 2016 06:53:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Anders Lindgren <andlind <at> gmail.com>:
bug acknowledged by developer.
(Sun, 03 Apr 2016 06:53:01 GMT)
Full text and
rfc822 format available.
Message #213 received at 22145-done <at> debbugs.gnu.org (full text, mbox):
John Wiegley <jwiegley <at> gmail.com> writes:
>>>>>> Michael Albinus <michael.albinus <at> gmx.de> writes:
>
>> Given, that the last problems related to OS X have been solved by commit
>> df441b362c25c4ad59ea3d83137328d0d4098eaf, I believe we could close this bug.
>> Do you agree?
>
> OK, if you think this is a Nix bug and not an Emacs bug, then I'll take
> responsibility from here for the Nix fix and you can close this issue.
Done. However, I haven't said it is a Nix *bug*. I believe it is rather
a problem with the Nix *environment*.
IIRC, the problem was something like this on hydra.nixos.org years ago:
Tramp needs several programs in $PATH to run correctly. Usually, they are
found on every machine.
Nix does not offer them in general, because they are also tested in the
Nix environment, as part of coreutils or so. Therefore, they could be
found only by the user's local $PATH, which is set by Nix accordingly.
In order to fix this, tramp-tests.el checks whether we are in a Nix
environment (when (getenv "NIX_STORE"), and adds the local $PATH
settings then. Maybe this test does not work on your machine, and
$NIX_STORE isn't set? Then you need to test something else.
You could also add the local $PATH to Tramp's setting mandatory. Just
remove the check (getenv "NIX_STORE"). When it works, we know that this
is your problem (the same I have had years ago), and we must find a
better check for determining a Nix environment.
I do *not* want to add local $PATH settings in general for the tests,
because this would make the test indeterminable.
> Thanks for helping me debug this!
HTH. Best regards, Michael.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sun, 01 May 2016 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 9 years and 47 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.