Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Uncaught exception Failure("input_value: bad bigarray kind") #94

Closed
gerroon opened this issue Sep 17, 2017 · 67 comments
Closed

Uncaught exception Failure("input_value: bad bigarray kind") #94

gerroon opened this issue Sep 17, 2017 · 67 comments

Comments

@gerroon
Copy link

gerroon commented Sep 17, 2017

Debian testing x64 Unison 2.48.3(Deb packages) <-> Debian Wheezy x32 Unison 2.48.4 (Github build)

Uncaught exception Failure("input_value: bad bigarray kind")
Raised by primitive operation at file "/tmp/buildd/unison-2.48.3/remote.ml", line 453, characters 18-45
Called from file "/tmp/buildd/unison-2.48.3/remote.ml", line 459, characters 23-61
Called from file "/tmp/buildd/unison-2.48.3/lwt/lwt.ml", line 75, characters 20-23
Re-raised at file "/tmp/buildd/unison-2.48.3/lwt/lwt.ml", line 135, characters 12-13
Called from file "list.ml", line 73, characters 12-15
Called from file "/tmp/buildd/unison-2.48.3/lwt/lwt.ml", line 31, characters 2-37
Called from file "/tmp/buildd/unison-2.48.3/lwt/lwt.ml", line 83, characters 17-46
Called from file "/tmp/buildd/unison-2.48.3/lwt/generic/lwt_unix_impl.ml", line 147, characters 6-40
Called from file "/tmp/buildd/unison-2.48.3/uigtk2.ml", line 3581, characters 6-125
Called from file "/tmp/buildd/unison-2.48.3/uigtk2.ml", line 156, characters 18-22
@brabalan
Copy link
Collaborator

This happens when unison is not compiled with the same version of ocaml on both machines. I don't know the ocaml version used in debian testing, but you should install the same one to compile in debian wheezy.

@gerroon
Copy link
Author

gerroon commented Sep 18, 2017

Hi

Well they actually sync with some other profiles. So they do not seem to have this issue always. This issue happens only with one of the sync profiles I use.

@brabalan
Copy link
Collaborator

If I remember correctly, it does not happen all the time. It depends on what is being synchronized.

@gerroon
Copy link
Author

gerroon commented Sep 18, 2017

@brabalan

Thanks for your reply. I will try it with the proper builds.

@hlovdal
Copy link

hlovdal commented Oct 16, 2017

This problem has not been fixed in many years and it is extremely frustrating that an otherwise very nice piece of software that you rely on suddenly just breaks after some update and becomes useless.

Would you like if your phone started crashing when you tried to call people that had phones with a newer or older version of Android than you have? Because that is how unison currently behaves.

@bcpierce00, please devote all your effort into solving this bug once and for all.

So in an effort to help come to the bottom of this problem I have some questions:

  1. What kind of protocol handshake is done when the local unison entity connects to a remote entity and what options are negotiated?

NB, I am not interested in the transport layer parts, e.g. ssh or socket, nor the rsync file content synchronisation part. Only the unison link layer protocol.

  1. Where is this documented?

  2. Which unit tests cover this?

I have reviewed all the other open issues, and in my opinion none of them are more important to solve than this (with failing on symlinks being the most serious candidate to be almost as important).

I have been using unison for many years (I know for sure I used it to sync between my laptop and desktop when studying, finished in 2006) but I do not know ocaml (I have mainly programmed in C).

@snowgoon88
Copy link

snowgoon88 commented Oct 23, 2017 •
edited

I do not know if it helps but I encountered this bug and explored a bit, while synchronizng on 2 computers : debian testing and ubuntu 17.04

It is a strange bug as only one file can make the difference, even on a "fresh" synchronization states. It is a simple text file, a Makefile text. Strange no ?

What can I do to help more ?

This is what I did
0) I tried synchronization as usual, ran into the bug.
1) I have deleted all my unison archive files, on both computer
2) I have synchonized again, with a specific rule to ignore THE file responsible of the "bug"
=> it works
[config file.prf]
ignore = Name Textes/Presentations/161004_MDP_INRA/Makefile

3) I comment the specific rule to ignore the file => it bugs
[config file.prf]
#ignore = Name Textes/Presentations/161004_MDP_INRA/Makefile

$> unison config_file
new file <==== new file Textes/Presentations/151215_Psyphine/Makefile [] <

Proceed with propagating updates? [] y
Propagating updates
...
[BGN] Updating file Textes/Presentations/161004_MDP_INRA/Makefile from //nacon//mnt/homedir_XXX to /home/XXX/Work/Loria
Unison failed: Uncaught exception Failure("input_value: bad bigarray kind")
Raised by primitive operation at file "/tmp/buildd/unison-2.48.3/remote.ml", line 453, characters 18-45
Called from file "/tmp/buildd/unison-2.48.3/remote.ml", line 459, characters 23-61
Called from file "/tmp/buildd/unison-2.48.3/lwt/lwt.ml", line 75, characters 20-23
Re-raised at file "/tmp/buildd/unison-2.48.3/lwt/lwt.ml", line 135, characters 12-13
Called from file "list.ml", line 73, characters 12-15
Called from file "/tmp/buildd/unison-2.48.3/lwt/lwt.ml", line 31, characters 2-37
Called from file "/tmp/buildd/unison-2.48.3/lwt/lwt.ml", line 83, characters 17-46
Called from file "/tmp/buildd/unison-2.48.3/lwt/generic/lwt_unix_impl.ml", line 147, characters 6-40
Called from file "/tmp/buildd/unison-2.48.3/main.ml", line 202, characters 6-24
Called from file "/tmp/buildd/unison-2.48.3/main.ml", line 131, characters 4-9

Fatal error: Lost connection with the server

4) add again the specific ignore rule => it works !!
[config file.prf]
ignore = Name Textes/Presentations/161004_MDP_INRA/Makefile

$> unison nacon_Textes
...
Synchronization complete

@bcpierce00
Copy link
Owner

Do you know what version(s) of the OCaml compiler was/were used on the two sides?

@snowgoon88
Copy link

This is hard to tell.

I can say that the package version of ocaml on ubuntu 17.04 is 4.02.3-6 and it is 4.02.3-10 on debian testing. I assume these are the version used....

But libraries have also version numbers. For example, on ubuntu 17.04, liblwt-ocaml-dev is 2.5.2-1 and 2.5.2-2 on debian testing.

@bcpierce00
Copy link
Owner

OK, so it seems likely that the ocaml version is the same on both sides.

And if you invoke Unison with "-path ..." to select just the file that failed in your previous tests, does it succeed or fail?

(And if it fails, then can you do the same thing and also add "-debug all" and post the resulting trace here or send it to me?)

@bcpierce00
Copy link
Owner

(And, for good measure, maybe also add "-debug verbose" to get an even longer trace and post/send that too?)

@snowgoon88
Copy link

Sorry, I forgot...
So I've cleaned up my archives files and run :

'$> unison -debug verbose -root ssh://dutech@nacon//home/dutech/Loria -root /home/dutech/Work/Loria -path Textes/Presentations/161004_MDP_INRA/Makefile > stdout_dump.txt 2> stderr_dump.txt'

That gives me these two dump files.
stdout_dump.txt
stderr_dump.txt

Hope that helps.

@torrentkino
Copy link

I stumbled upon this too. I have two versions of a SQLite file. Sync it one way and it crashes. Do it the other way around and it works. The file size is about 8MB.

Machine 1

  • Debian/SID 64Bit
  • Unison 2.48.4-1

Machine 2

  • Debian/Stretch 64Bit
  • Unison 2.48.3-1

Result

Unison failed: Uncaught exception Failure("input_value: bad bigarray kind")
Raised by primitive operation at file "/tmp/buildd/unison-2.48.3/remote.ml", line 453, characters 18-45
Called from file "/tmp/buildd/unison-2.48.3/remote.ml", line 459, characters 23-61
Called from file "/tmp/buildd/unison-2.48.3/lwt/lwt.ml", line 75, characters 20-23
Re-raised at file "/tmp/buildd/unison-2.48.3/lwt/lwt.ml", line 135, characters 12-13
Called from file "list.ml", line 73, characters 12-15
Called from file "/tmp/buildd/unison-2.48.3/lwt/lwt.ml", line 31, characters 2-37
Called from file "/tmp/buildd/unison-2.48.3/lwt/lwt.ml", line 83, characters 17-46
Called from file "/tmp/buildd/unison-2.48.3/lwt/generic/lwt_unix_impl.ml", line 147, characters 6-40
Called from file "/tmp/buildd/unison-2.48.3/main.ml", line 202, characters 6-24
Called from file "/tmp/buildd/unison-2.48.3/main.ml", line 131, characters 4-9

Absolutely reproducible. I could also provide those files in private if desired.

Aiko

@bcpierce00
Copy link
Owner

bcpierce00 commented Nov 17, 2017 via email

@DavidOliver
Copy link

I was having this issue after editing tags of some FLAC files. I'm now using precompiled binaries from Charlie Herron on both machines (using the servercmd option), and syncing is once again working okay.

Thanks for Unison!

@bcpierce00
Copy link
Owner

bcpierce00 commented Nov 24, 2017 via email

@Debilski
Copy link

@bcpierce00 How would I solve this problem on a shared Linux cluster that I maintain but where a certain number of users expect their own version of Unison (who knows which OS they have locally) to work with whatever is on the cluster?

@bcpierce00
Copy link
Owner

I'm afraid you may need to ask people to make sure whatever version of Unison they are using is compiled with an OCaml compiler with version >= 4.02.0. (4.02.0 was released over three years ago, so this is not an outlandish requirement.)

@stollem stollem mentioned this issue Dec 4, 2017
Closed
@stollem
Copy link

stollem commented Dec 4, 2017

Hi,

I have the same problem, but I believe both versions of unison were compiled with the same OCaml compiler version.

One version of unison is from Raspbian (based on Debian Stretch) and the other version is from Ubuntu 16.04 LTS.

Assuming on both systems the package maintainer compiles with the platform default version of OCaml, they both should've been compiled from OCaml 4.02.3:

Ubuntu 16.04:
2017-12-04 21:14:48 (+0100) $ apt-cache policy ocaml
ocaml:
Installed: (none)
Candidate: 4.02.3-5ubuntu2
Version table:
4.02.3-5ubuntu2 500
500 http://ch.archive.ubuntu.com/ubuntu xenial/universe amd64 Packages
mstoll@MartinAsusZen:~
2017-12-04 21:14:51 (+0100) $ apt-cache policy unison
unison:
Installed: 2.48.3-1ubuntu1
Candidate: 2.48.3-1ubuntu1
Version table:
*** 2.48.3-1ubuntu1 500
500 http://ch.archive.ubuntu.com/ubuntu xenial/universe amd64 Packages
100 /var/lib/dpkg/status

Raspbian:
mstoll@Squeezeplug-Wozi /etc/apt $ apt-cache policy ocaml
ocaml:
Installed: (none)
Candidate: 4.02.3-9+rpi1
Version table:
4.02.3-9+rpi1 500
500 http://mirrordirector.raspbian.org/raspbian stretch/main armhf Packages
mstoll@Squeezeplug-Wozi /etc/apt $ apt-cache policy unison
unison:
Installed: 2.48.3-1
Candidate: 2.48.3-1
Version table:
*** 2.48.3-1 500
500 http://mirrordirector.raspbian.org/raspbian stretch/main armhf Packages
100 /var/lib/dpkg/status

  1. Is there a way to verify this?
  2. Is it possible that the CPU architecture (32 vs 64-bit, even) influences the serialization format?

@bcpierce00
Copy link
Owner

bcpierce00 commented Dec 4, 2017 •
edited

Is there a way to verify this?

Ask the package maintainers?

Is it possible that the CPU architecture (32 vs 64-bit, even) influences the serialization format?

I don't think so, but perhaps @brabalan knows more?

@stollem
Copy link

stollem commented Dec 4, 2017

ok, so I recompiled both packages from sources (took a while on the Pi, but was otherwise easy, thanks to dpkg-buildpackage). It now works. I would have to conclude that either the Raspbian or the Ubuntu package was not compiled with a version of ocaml that's not the default for that distro on that version.

@felbinger felbinger mentioned this issue Jan 15, 2018
Closed
@jknechtel
Copy link

Hi @stollem, do you have that Raspbian Stretch running on a Pi 3 Model B, by any chance? If so, we'd have the very same setup, and I also have those bug issues. I'd be happy if you could share your compiled packages which resolved this :)

@stollem
Copy link

stollem commented Jan 15, 2018

Sure: https://drive.google.com/open?id=1I5HqTKoRqbMWPKIlFIEd0oQ3Ahs_jv0i

@jknechtel
Copy link

Many thanks @stollem, unison works perfectly fine again :)

@lepalom
Copy link

lepalom commented Apr 24, 2018

I'm having the same issue but with a Debian 9 Stretch amd64 server and Kubuntu 16.04 client.

I have tried to build unison in Debian Stretch with the same version of Kubuntu, but I'm afraid that I have to rebuild ALL the ocaml-nox dependencies and it's not affordable.

I cannot understand why this strong dependency. It has no sense. I should have an unison server and run ANY client to connect.

Any idea to solve this?

@bcpierce00
Copy link
Owner

bcpierce00 commented Apr 24, 2018 via email

@hlovdal
Copy link

hlovdal commented Apr 24, 2018

there was an incompatible change to the wire format for marshaled values between OCaml 4.01 and 4.02, so even the same versions of Unison will not work if they are compiled with different compilers from before and after this change.

So in other words, the OCaml compiler developers don't give a shit about keeping binary compatibility (for any version, including minor bugfixes). Thus the internal OCaml marshal functionality is fundamentally unreliable and unsuitable as a means for external communication for unison.

@bcpierce00, you need to find an external marshalling library which has a stable and versioned interface and use that, so that unison is able to detect and handle version mismatches in a proper way instead of failing catastrophically like it has done for many years due to ocaml's carelessness for binary compatibility.

Using an external marshalling library is the only way to achieve reliable communication. Continuing using the internal stuff is guaranteed to result in future problems.

@bcpierce00
Copy link
Owner

Not likely I'm going to do that myself, but I'd be happy to consider a PR...

@bcpierce00
Copy link
Owner

"What can be done oil the Debian end?" is a question for Stephane. But if you are able to build on both machines it should not be very hard to install the same version of OCaml on both sides and then recompile Unison.

@g-raud
Copy link
Contributor

g-raud commented Sep 5, 2018 via email

@lepalom
Copy link

lepalom commented Sep 6, 2018 via email

@Encrypt
Copy link

Encrypt commented Sep 18, 2018

Hello everyone and thank you for your answers!

As mentioned by @lepalom, I've checked the version of the Unison package installed.
On my desktop computer, it is indeed version 2.48.3-1+b1.
On my Raspberry Pi, however, it is version 2.48.3-1.

So, I guess there is a "faulty" version on the Raspberry Pi.
Do you also maintain the unison package for such a computer @glondu?

As @bcpierce00 mentions, I could also recompile Unison (which I already did a few times before).
But I prefer using packages for all their benefits! 😛

@lepalom
Copy link

lepalom commented Sep 18, 2018

Check here:

https://packages.debian.org/stretch/armel/unison/download

If I'm not wrong for Raspberry Pi, armel arch is the correct one.

@glondu
Copy link
Collaborator

glondu commented Sep 20, 2018

@Encrypt Raspbian is a derivative of Debian with its own procedures. You should ask them to recompile Unison, they must have a procedure for that. You can refer them to the Debian bug.

@lepalom According to this, using Debian's armel (or armhf) binary packages on Raspbian is not recommended.

@fauust
Copy link

fauust commented Oct 17, 2018

Hi,
workaround on raspbian (armhf):

$ sudo apt purge unison
$ wget http://http.us.debian.org/debian/pool/main/u/unison/unison_2.48.3-1+b1_armhf.deb
$ sudo dpkg -i unison_2.48.3-1+b1_armhf.deb

I have just filled a report for rasbian team:
https://bugs.launchpad.net/raspbian/+bug/1798438

Regards

@Encrypt
Copy link

Encrypt commented Oct 20, 2018

Hello guys!

First of all, thank you for the help you have all given me regarding this issue.
I followed the updates here and considered the workarounds you gave.

I have good news though: an "apt-get update && apt-get upgrade" on my Raspberry Pi brought a new Unison package, version 2.48.3-1+b1!
It seems the problem was fixed "on the packaging side" and I could successfully run unison this evening to synchronise my two computers.

I'll have a closer look at how to create bug reports since I have never done any.
Thanks @fauust for that!

Cheers!

@andreasabel
Copy link

First of all, big thanks to the Unison developers for this excellent trustworthy tool I have been using for more than 15 years now!!

Then the problem:
I also ran into this issue when trying to synchronize between Mac and Linux.
I had installed the following binaries:

Wishlist @bcpierce00 @brabalan

  • release interoperable binaries for the three major OSs in a single release
  • clearly point out on the release page which versions do or do not work together

Since the latest Linux binaries are 2.48.4, I could try the Mac version 2.48.15, but there is no indication which Ocaml version has been used for these binary, so I will be just shooting in the dark.

@wosc
Copy link

wosc commented Dec 17, 2018

So @bcpierce00, with which ocaml compiler version were the current binaries built? And can that be found out afterwards or do you "have to know"?

Background: I'm trying to connect a mac and an ubuntu machine. The version available via apt is 2.48.3, but using the corresponding mac binary yields the dreaded bigarray error. Okay, so let's get caught up to the currently published 2.51 instead. Whelp, no binaries for linux in sight (see #200), so I'll have try and compile unison for linux myself -- but if I'm going through that trouble, I'd like to make sure I'm at least using a compatible ocaml compiler version.

Thanks for your help!

@bcpierce00
Copy link
Owner

bcpierce00 commented Dec 17, 2018 via email

@wosc
Copy link

wosc commented Dec 18, 2018

Thanks, I'll try and check unison -version then.

But... you do realize that "any compiler of the last few years" is utterly incorrect?

For example: The 2.48.3 OSX binary was "released on 29 Sep 2016", and the corresponding Debian binary is from around August 2015. Does this not both count as "last few years"? However they do not work together, which is the whole point of this long, long bug report right here.

(By those release dates I'm guessing they were compiled with 4.03 and 4.02, respectively, but I don't know because that unsion -version just reports the unison version number.)

@bcpierce00
Copy link
Owner

The switch to OCaml 4.02, which is where the breakage occurred IIRC, was in 2014. So, indeed, I should have said "last two or three years."

@wosc
Copy link

wosc commented Dec 18, 2018

Ah. So it's not every compiler version that breaks the serialization. That's good to know (earlier comments here sounded way more ominous to me about how strict the compatibility dependency on the compiler might be).

With these hints, I've been quite successful!

  • I found out that the 2.51.2 macOS binary that's on the github release page was compiled with ocaml-4.04.
  • I've managed to compile unison-2.51.2 with an Ubuntu-18 VM, which ships with ocaml-4.05. (I've quickly aborted attempts at compiling my own 4.04, since I would have had to recompile the whole ocaml world of gtk libraries to match exactly that compiler version, had I wanted to persevere.)
  • Those two versions now are able to talk to each other \o/

Thanks again for your help! But yeah, another vote from me to send the Debian folks some cookies and get 2.51 included there (#200). This is really quite the hassle, I really enjoy using unison, but the way to get there is currently rather rocky.

@randoum
Copy link

randoum commented May 18, 2019

With unison version 2.48.3 on MacOSX and unison version 2.48.3 on Debian (yes, 2.48.3 on both sides)
But still got the error Unison failed: Uncaught exception Failure("input_value: bad bigarray kind")

@Bessonov
Copy link

Interesting, it worked with 2.48.3 on raspi and static compiled 2.48.4 on ubuntu for many years. After editing an encrypted file through sshfs from a VM, I've got the same error. If I try to synchronize other files, then everything is fine. After copying the file through rsync -avz -P the error is gone.

@davidcallen
Copy link

I hit this error using 2.40 installed from standard repository on a Fedora 29 laptop when syncing to a QNAP NAS.
The QNAP NAS had to build 2.40 and modify code to workaround the SVN issue :
#103

Other newer versions I tried to build failed in different ways, and likewise on Fedora 29, so getting a comparable version of Unison seemed fairly difficult. It seems awkward that Unison does not have an API that provides better compability i.e. unison versions can differ but still be compatible.

Anyway now I hit error "input_value: bad bigarray kind" when syncing a single text file.... Sigh.
I read that now I need comparable versions of ocaml compiler. With the NAS being an embedded device this is now probably a blocker for me. Trying to compile a new version of ocaml on there would probably take days and be quite difficult (if anything like building GCC).
I very much appreciate efforts of the maintainers (I am also a programmer) but I humbly ask that if at all possible please add a seldom broken API for better compatibility. I would really like to use Unison but I think will now have to retreat to GoogleDrive or somesuch.

On NAS :
$ ocaml -vnum
3.12.0
$ unison -version
unison version 2.40.191

NAS unison built with "make UISTYLE=text NATIVE=false"

On Fedora 29 :
$ ocaml -vnum
4.07.0
$ unison -version
unison version 2.40.128

@niol
Copy link

niol commented Jan 30, 2020

One solution would be to migrate from using https://caml.inria.fr/pub/docs/manual-ocaml/libref/Marshal.html which may be dependant on the ocaml compiler version to something with a specification, maybe https://github.com/janestreet/bin_prot

@hlovdal
Copy link

hlovdal commented Feb 1, 2020

Not just one solution. Discarding the fundamentaly unreliable internal ocaml marshaling and replace it with something else that is reliably is the only solution.

My very strong suggestion is to use protobuf since that is a extremely mature project and is well documented. Started internally at Google in 2001 and publicly released in 2008. It has received a massive amount of testing; more testing than any other alternative suggested here. And there is zero risk that one single maintainer of a library looses interest and stops maintaining it. Protobuf will be maintained longer than unison will.

https://ocamlverse.github.io/content/protocols.html has the following entry for protobuf:

Protobuf

Again, this bug should be the top priority.

@bcpierce00
Copy link
Owner

bcpierce00 commented Feb 1, 2020 via email

@glondu
Copy link
Collaborator

glondu commented Feb 4, 2020

I’d be interested in switching to something more stable than the Marshal library has turned out to be.

Glad to hear that!

I do not have time to do this myself. Someone else would need to take it on.

I gave it a try, using ppx_deriving_protobuf: https://github.com/glondu/unison/tree/protobuf

It took me two days. It seems to work (at least on Linux), but needs more testing.

It would be a shame to increase the difficulty of building Unison.

Installing build-dependencies is easy with opam, but it might indeed be difficult to bring them in a non-opam environment, such as when packaging for another distribution.

Updating the Makefile-based build system turned out to be very easy, thanks to ocamlfind. I don't know dune enough to update the dune-based build system.

Switching to something better than Marshal will [...] not help compatibility with all the older versions that are out there.

My goal here was for Unison to keep compatibility with itself compiled with another OCaml version. Technically, my proposal moves the compatibility issue to ppx_deriving_protobuf itself, but the ppx ecosystem seems to be well-behaved and supported (but only time will tell).

If one were going to revamp the protocol [...]

This is not what I did. My changes are simple and systematic (even though the diff is big).

Changes that could possibly affect performance or usability are:

  • replaced all Bytearray.t by bytes
  • replaced all bigarrays by arrays
  • read the archive into a bytes instead of directly from an in_channel

Notably on 32 bit systems, some limits might be reached more easily.

@m-fonseca
Copy link

Hello, I'm trying to use unison for the first time and I can't because of this particular issue. (Trying between debian buster and debian bullseye). I ended up compiling unison version 2.48.4 statically to try to get around this problem. But I'm still running into trouble.

Uncaught exception Failure("input_value: ill-formed message")
Raised at file "/srv/tmp/unison/unison/src/lwt/lwt.ml", line 126, characters 16-23
Called from file "/srv/tmp/unison/unison/src/lwt/generic/lwt_unix_impl.ml", line 102, characters 8-23
Called from file "/srv/tmp/unison/unison/src/update.ml" (inlined), line 2096, characters 2-69
Called from file "/srv/tmp/unison/unison/src/uitext.ml", line 700, characters 16-56
Called from file "/srv/tmp/unison/unison/src/uitext.ml", line 788, characters 6-90
Called from file "/srv/tmp/unison/unison/src/uitext.ml", line 810, characters 19-66
Called from file "/srv/tmp/unison/unison/src/uitext.ml", line 870, characters 21-43

While searching for this error, I was lead here. Is this somehow the same marshaling problem or is this a separate issue all together?

Thanks

@glondu
Copy link
Collaborator

glondu commented Feb 18, 2020

Trying between debian buster and debian bullseye

These two are using different versions of OCaml, so expect trouble.

I ended up compiling unison version 2.48.4 statically to try to get around this problem.

Do you use the same binary on both sides? (Did you set "servercmd" on the local side so that it points to the right binary on the remote side?)

@hlovdal
Copy link

hlovdal commented Feb 18, 2020

One thing that can be done immediately to prepare to switch to something other than the internal ocaml marshalling is to write code to negotiate the marchalling algorithm to use when the program starts a connection.

Unless the existing, olders clients does not have a problem with such a new negotiation addition to the communication, the sending part should be disabled when making releases, but by having all versions since now ready to receive will make switching later just work out of the box for all the latest releases.

@m-fonseca
Copy link

Trying between debian buster and debian bullseye

These two are using different versions of OCaml, so expect trouble.

I ended up compiling unison version 2.48.4 statically to try to get around this problem.

Do you use the same binary on both sides? (Did you set "servercmd" on the local side so that it points to the right binary on the remote side?)

Yes, in fact I had already removed the debian packages of unison from both sides, so it couldn't work otherwise. I also tried this using the socket mode (where I explicitly called the correct unison binary on the server side), and it gave me the same results.

@niol
Copy link

niol commented Mar 11, 2020

@glondu I see that you are experimenting with protobuf and bin-prot. I'd be happy to give a try, which one of the solution do you think is more promising?

@gdt
Copy link
Collaborator

gdt commented Sep 14, 2020

This is basically all about #375 and #377, and packaging-system issues. Closing as a dup.

@gdt gdt closed this as completed Sep 14, 2020
@glondu
Copy link
Collaborator

glondu commented Sep 15, 2020

I see that you are experimenting with protobuf and bin-prot. I'd be happy to give a try, which one of the solution do you think is more promising?

@niol protobuf and bin-prot had their own shortcomings, I eventually ended up with my own implementation: https://github.com/glondu/unison/tree/umarshal

@hlovdal hlovdal mentioned this issue Oct 9, 2020
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests