Unison hangs with no progress from "Contacting Server..." dialog when a password is required to be entered. This is caused by the upgrade to OpenSSH 5.6 and is a known issue i.e. : https://bugs.archlinux.org/task/20877 It may be the root cause of bug #335107 which was closed on a workaround.. I have modified the Arch patch and this corrects the issue. Will attach. Reproducible: Always Steps to Reproduce: 1. Ensure x11-ssh-askpass _is_ installed 2. Start Unison sync with SSH root requiring password to be entered 2. Hit "Go" 3. Dialog with "Contacting Server..." will be shown.. but will not progress
Note : This has been mentioned on the Forums with no fix.. : https://forums.gentoo.org/viewtopic-t-843358.html?sid=b51df510dccb449d2ecbe3942db859fa
Created attachment 255697 [details, diff] Source patch correcting the hangup.
Created attachment 255699 [details] Modified Ebuild For Overlay Test (Only change is to apply patch supplied)
Created attachment 255701 [details] Original Patch from Arch Linux Bugtracker for Comparison - Note second section seems already applied in source code...
Note that 2.32.52 does _not_ correct this issue and the same or similar patch will be needed to be applied to this. The next stable release of Unison after this should not require this patch as it is in upstream SVN.
I can confirm working of the patch, please provide this ebuild in the portage tree.
Arch patch works, amd64-desktop
Ebuild unison-2.27.57-r2 works fine for me. THX!
Works good. No Problems. (3 PC)
Could we fix this in Portage? As this is definitely a tool that´s installed on multiple PCs per User, running arund applying the patch to all my machines is a tedious work. "unison -ui text" still works for me, refraining from using the gui for now.
(In reply to comment #10) > Could we fix this in Portage? As this is definitely a tool that´s installed on > multiple PCs per User, running arund applying the patch to all my machines is a > tedious work. > > "unison -ui text" still works for me, refraining from using the gui for now. > Same here, could someone please add the patch to portage?
The patch is already in portage since august 2010. But here it doesn't fix the problem. Running unison 2.32.52.
(In reply to comment #12) > The patch is already in portage since august 2010. But here it doesn't fix the > problem. Running unison 2.32.52. > I'm sorry but I think that it's not. Indeed, if I apply it, my Unison works and without it, it doesn't... Best.
Please fix it in portage. Iam using the patch since 3.December 2010 without problems. The portage version 2.27.57-r1 does not work.
Above two comments are true: Unison 2.32.52 doesn't work on my system, with openssh 5.8_p1-r1. Had to create a new local ebuild, with a single line to patch source against this: Index: src/terminal.ml =================================================================== --- src/terminal.ml (revision 471) +++ src/terminal.ml (working copy) @@ -191,7 +191,6 @@ exit 127 end | childPid -> - Unix.close slaveFd; (Some masterFd, childPid) end Now everything works again. This should really be fixed; although gentoo user are skilled, I think they should spend their time in something more interesting than developing local ebuilds for trivial tasks...
Created attachment 265573 [details] Local ebuild for building a working unison 2.32.52 (quick-and-dirty; only a single line added: 36)
(In reply to comment #15) > This should really be fixed; although gentoo user are skilled, I think they > should spend their time in something more interesting than developing local > ebuilds for trivial tasks... Well... is there anyone capable of doing this? it's really annoying particularly because there exists a solution.
Could someone please add this patch to portage? (At least for the stable version of Unison.) I put the fix into a local overlay fifteen months ago, and then forgot about it, so when I installed Gentoo recently I spent an hour running around trying to find out (again) what had broken. A one-line patch would save a lot of people a lot of work. Thanks - Will
I can confirm that this patch applies cleanly to unison-2.13.16, unison-2.27.57, unison-2.27.157, and unison-2.32.52. No issues compiling or running these versions on x86. It has been applied by upstream to the 2.40 branch.
we realy need to get forward whis this. patch is working here since a long time om several machines.
I agree... it's been more than a year (again). Is anyone on point for this sort of thing? It's not like making a local overlay, downloading the patch etc is particularly difficult, but this one line fix would save a decent chunk of time
Hi, thank you for the comments and patches. I am using unison-2.40 myself, therefore not sure of this bug. I'd like to know why the upstream applied the patch to 2.40 but have not backported it to older versions. To commit a patch (not to say I don't understand ocaml) I do not use/test myself does not feel good. If you care about <unison-2.40 and want to maintain this patch, I'd be happy to proxy-maintain it. Or, which is much welcomed, becoming a developer to maintain unison. Cheers!
I don't think i can handle the dev thing for the lower versions, but at least the not working versions should be masked. Having a stable version that do not work at all seems to be worse than having only newer versions available (even if they are not stable). On the other hand the patch seems to work for several people here flawless, Therefore i don't see the problem to apply it. Could this patch change introduce any security problems? Maybe >2.40 should be stabilized too?!
2.27.57-r1, the last stable version, is still broken on x86. I see that I patched it locally in November 2011; I've just had another fight to get unison going because I'd forgotten it needed patching. Be nice if the (one line) patch could make it into Portage; not everyone remembers the bugs of 2011. Will
this should be solved in the current versions in testing (stable keyword was dropped some time ago)
