Since the upgrade to 2.48.4-1, I get when synchronizing with
a Debian/stable server:

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

[...]

https://github.com/bcpierce00/unison/issues/94 says:

"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."

The reporter used wheezy there, but in my case, this is between
unstable (this version) and stretch.

I can confirm this bug

Le 31/10/2017 à 18:43, Vincent Lefevre a écrit :

This is a known issue, and not easy to fix. Upstream is not interested
to make unison compatible with other versions of itself (or same version
compiled with another version of OCaml): Unison is designed to work only
with the same version, period.

I thought this was only for major versions. Anyway, there's still
the workaround that was used in past Debian releases (e.g. jessie):
provide the version from the previous release too, then make the
unison-all package depends on both packages. I've just submitted
a RFP bug for unison2.48.3:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880541

IMHO, the current unison package should not enter testing before
unison2.48.3 is available, or this would annoy users who synchronize
between testing and stretch (AFAIK, synchronization between
sid/testing and jessie was working too before this upgrade).

Le 02/11/2017 à 01:30, Vincent Lefevre a écrit :

The issue here is the version of ocaml used to compile unison. They must
coincide on both sides. (Actually, it is a change in ocaml 4.02 that
made unison incompable with itself when the version of ocaml differs,
that explains why we could provide "compatibility" packages before.)
Packaging unison2.48.3 won't solve the issue, since it would be compiled
with today's ocaml, therefore it would be incompatible with the version
in stretch. The way unisonX.YY.Z used to be packaged relied on the fact
that the version of ocaml didn't matter, which is no longer true.

And packaging multiple versions of ocaml just for unison is something
I'm not willing to do.

To synchronize between multiple releases of Debian (or Ubuntu), I use
schroot on one side so that both sides are identical. I know other
people directly copy the binary (the package or the executable) of one
side to the other.

I know this is inconvenient, but I find it more convenient than removing
unison from Debian altogether.


Cheers,

This will prevent one from automatically getting security updates,
for instance.

Alternatively, wouldn't it be possible to rename the current unison
package and make it co-installable with the one from stretch?

Since unison just depends on libc6, this shouldn't yield conflicts
preventing upgrades.

Vincent Lefevre <vincent@vinc17.net> writes:
compiled with the only OCaml compiler available in the current
Debian version, hence both unison's would be incompatible with
the one in stretch.

One side condition that you have to keep in mind is that there
are a lot of architectures and the OCaml team does source
uploads, which get compiled using the current Debian version.

As Stéphane pointed out already: Please discuss with the upstream
authors or submit patches there. Alternatively you could set up
inofficial repository version, where you provide unision packages
compiled with different OCaml versions.

Hendrik

the OCaml from stretch. And there are no dependencies on what could
be OCaml libraries, so that it is compatible with stretch machines
for synchronization. Currently I'm using

Package: unison
Pin: release n=stretch
Pin-Priority: 900

and I could check that it works. But the current issue with this
is that one cannot install the new Unison from unstable (to be
able to use new features between unstable/buster machines),
because in particular, the package from unstable has the same
name. Hence my proposal of renaming this package, e.g. to include
some (compatibility) version number in the package name.

Some other things may be needed to avoid conflicts on files
provided by the package.

This issue has existed for years, and any change is unlikely. More
importantly, even if this is fixed, the new version will still be
incompatible for synchronization with stretch and jessie. So, the
problem will still be there.