Description of problem: Synchronization between Fedora 21 and 22 does not work Version-Release number of selected component (if applicable): unison240-2.40.102-8.fc21.x86_64 (built with ocaml-4.01.0) unison240-2.40.128-1.fc22.x86_64 (built with ocaml-4.02.0) How reproducible: Always Steps to Reproduce: 1. Start unison and select profile 2. Start synchronizing changes 3. Dies with: Uncaught exception Failure("input_value: bad bigarray kind") Actual results (GUI): $ unison (unison:4448): GLib-GObject-WARNING **: The property GtkDialog:has-separator is deprecated and shouldn't be used anymore. It will be removed in a future version. Connected [//thinkpad//home/vbraun/Documents -> //volker-desktop//home/vbraun/Documents] Uncaught exception Failure("input_value: bad bigarray kind") (unison:4448): GLib-GObject-WARNING **: The property GtkWindow:allow-grow is deprecated and shouldn't be used anymore. It will be removed in a future version. Actual results (Text mode): UNISON 2.40.128 started propagating changes at 09:28:50.56 on 07 May 2015 [BGN] Updating file XXXX from //volker-desktop//home/vbraun/Documents to /home/vbraun/Documents [BGN] Copying XXXX from /home/vbraun/Documents to //volker-desktop//home/vbraun/Documents Uncaught exception Failure("input_value: bad bigarray kind") Fatal error: Lost connection with the server Additional info: This is apparently because of an incompatible change in ocaml between 4.01 and 4.02 , see * Summary: https://bugs.archlinux.org/task/43241 * Ocaml upstream: http://caml.inria.fr/mantis/view.php?id=6621 * Apparently fixed/worked around in unison-2.48.3: http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html#news
Please see discussion I just started on Fedora devel list.
https://lists.fedoraproject.org/pipermail/devel/2015-May/210443.html
(In reply to Richard W.M. Jones from comment #2) > https://lists.fedoraproject.org/pipermail/devel/2015-May/210443.html It looks like the different minor number for unison might not be the only reason why syncing between e.g. Fedora and Debian fails. https://bugs.archlinux.org/task/43241 suggests that "The bug occurs when one host's unison is compiled with ocaml < 4.02 and another with ocaml 4.02 because ocaml changed their serialization format in 4.02." ocaml in Debian testing for me is at version 4.01, so if it is the version used to compile unison, it might be that. That is the only discernible change that I see between the built package for unison in fc21, and the one in fc22. I will try to re-compile unison on debian with ocaml from experimental.
Correct, this particular issue happens because of the different version of OCaml. However I'm not keen to get involved with fixing bugs in this package at all until we have proper packaging.
I have upgraded my laptop from Fedora 21 to 22 and found that the unison240 is now quite unusable because of this very bug. (I use unison to sync files between Different computers, and not all of them can be upgraded at the same time to the same operating system). I hear that Unison version 2.48.3 has this bug fixed. Is it possible to make unison248 package or something like this? I do not really understand the "proper packaging" problem, and do not know how to get there. And do not who is responsible or willing to do this... Is there a workaround in the meantime for this bug? Is is safe to install this RPM not from Repo?: https://copr-be.cloud.fedoraproject.org/results/jujens/Unison/fedora-22-x86_64/unison248-2.48.3-1.fc21/unison248-2.48.3-1.fc22.x86_64.rpm
The workaround is to install the Rawhide package.
I experience the same problem. Unison is however also unstable when syncing between two Fedora 22 machines with exactly the same (sub-)version.
(In reply to Richard W.M. Jones from comment #6) > The workaround is to install the Rawhide package. Can you explain the workaround in a little more detail? I installed the latest Rawhide package to my Fedora 22 system. I still get the same error trying to sync with Fedora 21. It looks like Fedora 22 to Fedora 22 isn't working either from the most recent comment, though maybe that is a different bug. Are there any other ideas or workarounds people can suggest for getting Unison working or another program/routine that does the same thing? I depend on Unison heavily and each of my machines are slowly becoming islands. I know I can do cumbersome stuff with rsync, but Unison made it all SO easy. :) Sadly I'm not technical enough to submit patches, but I'm glad to help in other ways if someone can suggest them.
Can you try installing the Rawhide version on the F21 system. You should just be able to do: $ koji download-build unison240-2.40.128-2.fc23 $ sudo dnf install unison240-2.40.128-2.fc23.x86_64.rpm unison240-gtk-2.40.128-2.fc23.x86_64.rpm I just tried it now, and it installs fine - there are no non-F21 dependencies. However I did not test whether it interoperates with unison240 on a (real) Rawhide system - but if that doesn't work you need to talk to upstream.
(In reply to Richard W.M. Jones from comment #9) > Can you try installing the Rawhide version on the F21 system. You > should just be able to do: > > $ koji download-build unison240-2.40.128-2.fc23 > $ sudo dnf install unison240-2.40.128-2.fc23.x86_64.rpm > unison240-gtk-2.40.128-2.fc23.x86_64.rpm > > I just tried it now, and it installs fine - there are no non-F21 > dependencies. > > However I did not test whether it interoperates with unison240 > on a (real) Rawhide system - but if that doesn't work you need > to talk to upstream. Super! I'm back in business. Thank you. FWIW, the dnf command above didn't work for me, but 'sudo yum localinstall' did :)
I had a problem with synchronizing Centos 6.6 with Fedora 22. Rawhide workaround would not work for this case. And upgrading CentOS machine frm 6 to 7 is not an option yet, since it is a work machine, and OS versions are kept uniform. I have managed to manually compile Unison 2.48.3 on CentOS 6.6 so it would interoperate with Unison 2.48.3 which, in turn, I side-loaded onto Fedora 22. Now, after couple of days of trying different things, my setup finally works. Step by step description of what I did: On Fedora 22 I did: dnf remove unison240-text unison240 wget https://copr-be.cloud.fedoraproject.org/results/jujens/Unison/fedora-22-x86_64/unison248-2.48.3-1.fc21/unison248-text-2.48.3-1.fc22.x86_64.rpm wget https://copr-be.cloud.fedoraproject.org/results/jujens/Unison/fedora-22-x86_64/unison248-2.48.3-1.fc21/unison248-2.48.3-1.fc22.x86_64.rpm dnf install unison248-2.48.3-1.fc22.x86_64.rpm unison248-text-2.48.3-1.fc22.x86_64.rpm (note that this is not from the official repo, this comes from google, but is a newer version of unison, with some more bugs fixed - and just works). On CentOS 6.6 it was much trickier: I have downloaded sources from Unison website (unison-2.48.3.tar.gz). Then, I have tried to compile these, but compilation failed. This is because CentOS uses ocaml-3.11 and unison guys did the newest batch of programming in ocaml-4. Actually the "unison" executable compiles ok but compilation fails later, when it tries to build "fsmonitor" executable (there is a syntax error there). Unison then, even when compiled ok, will not work! Reason for this is some compatibility break with the way different OCaml versions handle some data structures. So, I had to install ocaml-4 compiler. Unfortunately it is not in standard Centos repos - the newest version there is 3.11. Fortunately, I did find proper Centos 6 repo for newest OCaml, here: http://software.opensuse.org/download.html?project=home%3Aocaml&package=ocaml yum remove ocaml ocaml-runtime cd /etc/yum.repos.d/ wget http://download.opensuse.org/repositories/home:ocaml/CentOS_6/home:ocaml.repo yum install ocaml then I went to the unison.2.48.3 sources, issued "make" command, and voila: unison executable was build with all new ocaml-4.02.1 Then, I put this executable in my "bin" and in order to make sure this executable is issued every time I connect to this computer from outside to sync, I use directive "servercmd=/home/user/bin/unison" in my unison profile file. Other way if to uninstall all other version of unison, for example unison240 which is the newest in the repos. I hope this will help somebody in similar situation.
Thanks a lot JanS, your technique works perfectly: For Fedora 22: * Get the latest unison 2.48 from https://copr-be.cloud.fedoraproject.org/results/jujens/Unison/fedora-22-x86_64/unison248-2.48.3-1.fc21/ For CentOS 6: * Get the latest ocaml from http://download.opensuse.org/repositories/home:ocaml/CentOS_6/home:ocaml.repo * Compile the unison 2.48 source code from https://www.seas.upenn.edu/~bcpierce/unison//download/releases/stable/ Avinash
Note the problem with unison is nothing to do with unison, but with the back end library. JanS solution works because he updated ocaml on his CentOS 6 box (and the unison built with that library), he probably did not need any change at all on the fedora 22 box.
(In reply to Richard W.M. Jones from comment #9) > Can you try installing the Rawhide version on the F21 system. You > should just be able to do: > > $ koji download-build unison240-2.40.128-2.fc23 > $ sudo dnf install unison240-2.40.128-2.fc23.x86_64.rpm > unison240-gtk-2.40.128-2.fc23.x86_64.rpm For what it's worth, this didn't work around the problem in my case. I synchronize between a Fedora laptop and a server running CentOS 7. I believe unison on the CentOS server was built from 2.4.128 source using whatever ocaml came with CentOS. That worked on Fedora 20 and started failing on upgrade to Fedora 22.
(In reply to J. Bruce Fields from comment #14) > (In reply to Richard W.M. Jones from comment #9) > > Can you try installing the Rawhide version on the F21 system. You > > should just be able to do: > > > > $ koji download-build unison240-2.40.128-2.fc23 > > $ sudo dnf install unison240-2.40.128-2.fc23.x86_64.rpm > > unison240-gtk-2.40.128-2.fc23.x86_64.rpm > > For what it's worth, this didn't work around the problem in my case. I > synchronize between a Fedora laptop and a server running CentOS 7. I > believe unison on the CentOS server was built from 2.4.128 source using > whatever ocaml came with CentOS. That worked on Fedora 20 and started > failing on upgrade to Fedora 22. I'm also syncing between Fedora 22 and CentOS 7 and I upgraded to the 2.48 version as Avinash Meetoo suggested above in comment 12. I installed the Fedora packages into by CentOS box too and it worked like a charm. Just remember to point out the new unison executable with the -servercmd if you'r using it that way. /Tomas
I need to sync my F22 box to a Debian Wheezy server. I have tried many version suggested here to no avail. Which version is compliant with Debian Wheezy (unison-2.40.65)? I'm also happy to rebuild but I don't understand which version. Thanks for a hint!
(In reply to markusN from comment #16) > I need to sync my F22 box to a Debian Wheezy server. > I have tried many version suggested here to no avail. > > Which version is compliant with Debian Wheezy (unison-2.40.65)? > I'm also happy to rebuild but I don't understand which version. > > Thanks for a hint! The version which recently landed in Debian testing, 2.48.3-1 (https://packages.debian.org/stretch/unison), is recent enough and solves the problem for me when used in concert with the version from: https://copr-be.cloud.fedoraproject.org/results/jujens/Unison/fedora-22-x86_64/unison248-2.48.3-1.fc21/
(In reply to markusN from comment #16) > I need to sync my F22 box to a Debian Wheezy server. > I have tried many version suggested here to no avail. > > Which version is compliant with Debian Wheezy (unison-2.40.65)? > I'm also happy to rebuild but I don't understand which version. > > Thanks for a hint! A working (only workaround) solution for me is this: cd /tmp koji download-build unison240-2.40.102-8.fc21 dnf remove unison240 unison240-gtk unison240-text dnf install unison240-2.*.x86_64.rpm unison240-gtk-*.x86_64.rpm rm -f unison240-*2.40.*.fc*.rpm
(In reply to Matteo Settenvini from comment #17) > (In reply to markusN from comment #16) > > I need to sync my F22 box to a Debian Wheezy server. > > I have tried many version suggested here to no avail. > > > > Which version is compliant with Debian Wheezy (unison-2.40.65)? > > I'm also happy to rebuild but I don't understand which version. > > > > Thanks for a hint! > > The version which recently landed in Debian testing, 2.48.3-1 > (https://packages.debian.org/stretch/unison), is recent enough and solves > the problem for me when used in concert with the version from: > > https://copr-be.cloud.fedoraproject.org/results/jujens/Unison/fedora-22- > x86_64/unison248-2.48.3-1.fc21/
Thanks, markusN, your solution worked for me when I'm on a F23 box trying to synchronize with a remote box running F21.
This bug is still present in the F24 rpm. Installing the fc21 rpm as recommended by Raman on comment #19 still works.
Essentially there is no interop between "old" Unison and "new" Unison builds. As such I don't believe this bug can be solved in Fedora. It's something for upstream to fix.
(In reply to Richard W.M. Jones from comment #22) > Essentially there is no interop between "old" Unison and "new" > Unison builds. As such I don't believe this bug can be solved > in Fedora. It's something for upstream to fix. Multiple unison versions are generally available on Fedora, and can be selected via alternatives. Maybe unison248 could be split into unison248-ocaml401 and unison248-ocaml402?
There would be no way to build such versions of Unison in Fedora.
Created attachment 1249906 [details] Script to generate SRPM and build multiple unison/ocaml pairs Since I badly needed server support for various unison/ocaml pairs, I came up with the attached script. Usage should simply be ./unison-helper-script --srpm followed by the appropriate 'rpmbuild' command. The script as-is contains some unneeded pairs. Pairs are specified in the script as: # OS Unison OCaml ## Linux 2.40 4.00.1 ## Linux 2.40 4.01.0 ## Linux 2.40 4.01.0 ## Linux 2.40 4.02.0 ## Linux 2.40 4.02.2 ## Linux 2.40 4.02.3 ## MacOS 2.48.3 4.01.0 ## Windows 2.48.3 4.01.0 ## Windows 2.48.3 4.02.1 ## Windows 2.48.4 4.03.0 ## MacOS 2.48.15 4.02.0 Feel free to improve as you see fit.
(In reply to Anders Blomdell from comment #25) Forgot the all important get-source preamble... > Created attachment 1249906 [details] > Script to generate SRPM and build multiple unison/ocaml pairs > > Since I badly needed server support for various unison/ocaml pairs, I came > up with the attached script. Usage should simply be > ./unison-helper-script --get-source > ./unison-helper-script --srpm > ...
There's a deeper problem lurking. I consistently get the same error between two Fedora 24 systems running identical unison packages: unison240-gtk-2.40.128-4.fc24.x86_64
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.