Description of problem: Unison cannot synchronize with remote Version-Release number of selected component (if applicable): unison227-2.27.57-19.fc18.i686 (local) unison227-2.27.57-17.fc17.i686 (remote) How reproducible: 100% Steps to Reproduce: 1. run unison, tell it OK when it prompts about unavailable archives/new roots 2. 3. Actual results: Popup: "Fatal error Internal error: New archives are not identical. Retaining original archives. Please run Unison again to bring them up to date." Expected results: prompt to make sync decisions, synchronize Additional info: Broke after upgrade from Fedora 17 to Fedora 18 See Bug 892830 for unison240. (same problem: CLOSED ERRATA)
imho this is a good time to retire the old unison-227 package. that version is not maintained by upstream for...how many years? Alternatively you would need to backport the fix from 2.40.102 that addresses the differences between ocaml 3 and 4.
This seems to be related to the following: http://unix.stackexchange.com/q/52945/12336 https://trac.macports.org/ticket/35407
The same problem exists when trying to use a remote machine running RHEL and unison227-2.27.57-13.el6.x86_64 from EPEL. Makes unison on Fedora useless.
*** Bug 980195 has been marked as a duplicate of this bug. ***
(In reply to Daniel Riek from comment #3) > The same problem exists when trying to use a remote machine running RHEL and > unison227-2.27.57-13.el6.x86_64 from EPEL. > > Makes unison on Fedora useless. There's 0% chance that OCaml on RHEL 6 can be updated, so if the versions of OCaml are required to be the same, then there's no way we can fix the bug so Fedora <-> RHEL 6 conversions can work. Does anyone have a concrete technical link describing the problem? The nearest I can find is: http://tech.groups.yahoo.com/group/unison-users/message/10456 which describes a "hash function". Is this Hashtbl.hash? I wasn't aware that Hashtbl.hash had ever changed. OCaml 4 adds some new and differently named hash functions in Hashtbl, but I didn't know the existing one had changed.
Maybe this commit from unison 2.40 branch can help you? r511 | vouillon | 2012-09-17 16:09:03 +0200 (Mon, 17 Sep 2012) | 3 lines * Use hash function from OCaml 3.x for comparing archives, even when compiled with OCaml 4.x On the other hand I could just provide unison240 for rhel6. Basically that would solve this issue as well if we obsolete unison227.
if a unison240 version with the fix were available for rhel6 this issue would be a moot point. as gregor noted in comment 1 unison227 is obsolete. unfortunately, we've been stuck with it when one end of our synchronization setup is rhel6.
Created attachment 768170 [details] new-hash.patch So that others don't have to suffer using subversion as well, I have attached the patch which was mentioned in the comment above. It's pretty straightforward so could probably be applied to the unison227 package (although I didn't check that). I also submitted a request for an EL6 branch for unison240: https://bugzilla.redhat.com/show_bug.cgi?id=734531#c26
On the whole it's probably better to go with a (relatively) new version of unison, instead of trying to patch the ancient version. Therefore I have added unison240 in EPEL 6: http://koji.fedoraproject.org/koji/taskinfo?taskID=5569267
unison240-2.40.102-3.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/unison240-2.40.102-3.el6
The setup with the new unison240 for RHEL 6 is working out of the box after updating both machines. Solves my problem.
unison240-2.40.102-3.el6 has been pushed to the Fedora EPEL 6 testing repository.
unison240 version from epel-testing is working very well for me. thanks for the fix.
unison240-2.40.102-3.el6 has been pushed to the Fedora EPEL 6 stable repository.