Unison 2.53.8. #28851

jhjourdan · 2025-11-05T14:31:29Z

No description provided.

jhjourdan · 2025-11-05T15:01:13Z

There is something very weird happening with host-system-msys: I placed this package as conflciting with unison, so that Opam should refuse to install Unison on the Mingw port. Instead, opam uninstalls this package and installq host-system-msvc, defeating the point of host-system-msys. This looks like a bug in host-system-msys to me.

mseri · 2025-11-05T15:27:21Z

@jmid what is the correct syntaxt to be uninstallable on mingw?

jmid · 2025-11-05T16:31:53Z

I had something similar happen: #28478 (comment) 🤷

My current understanding is that the host-system- packages are just regular opam packages, and hence not necessarily a good fit for conflicts. Polite ping @dra27 - do you agree?

Rather than conflicts you can use

available: os != "win32" to disable on (MSys2-MinGW/Cygwin-MinGW/Cygwinports) Windows, leaving "pure Cygwin"
available: os != "win32" | os-distribution != "msys2" to disable on only MSys2 or something like
available: os != "win32" | (os-distribution != "msys2" & os-distribution != "cygwin") to disable only on MSys2-MinGW and Cygwin-MinGW
...

where we utilize the bottom table from here: https://github.com/ocaml/opam-repository/wiki/Depexts-os-distribution---os-family-values

jhjourdan · 2025-11-05T19:23:11Z

What's the values of the variables for the msvc port?

jhjourdan · 2025-11-05T20:12:32Z

The following did the trick:

available: (os != "win32" | host-system-msvc:installed)

Not particularly elegant.

mseri · 2025-11-05T20:23:52Z

Looks perfectly good to me :)
Thanks to both

jmid · 2025-11-06T08:32:34Z

The following did the trick:
available: (os != "win32" | host-system-msvc:installed)
Not particularly elegant.

The opam CI linter is failing with

Error in unison.2.53.8: error 34: Field 'available:' contains references to package-local variables. It should only be determined from global configuration variables: "host-system-msvc:installed"

I don't know how serious this is though. Is it "just" a bad-practice warning or does it mean that it is somehow broken to do so? 🤔

mseri · 2025-11-06T09:18:50Z

I don’t know, @rjbou or @kit-ty-kate what do you think?

kit-ty-kate · 2025-11-06T10:48:13Z

The following did the trick:
available: (os != "win32" | host-system-msvc:installed)

mmh, how did you test this? Package variables aren't supposed to be evaluated in the available field (hence the lint error).

I've tried the following for good measure, just in case there is something wrong with the code:

opam-version: "2.0"
available: dune:installed

but i'm unable to install it even if dune is installed, as expected.

kit-ty-kate · 2025-11-06T10:51:09Z

packages/unison/unison.2.53.8/opam

+available: (os != "win32" | host-system-msvc:installed)
+depends: [
+  "ocaml" {>= "4.08"}
+]
+depopts: [
+  "lablgtk3" {>= "3.1.0"}
+  "ocamlfind"
+  "host-system-msvc"


Something like that would work instead, for example:

Suggested change

available: (os != "win32" | host-system-msvc:installed)

depends: [

"ocaml" {>= "4.08"}

]

depopts: [

"lablgtk3" {>= "3.1.0"}

"ocamlfind"

"host-system-msvc"

depends: [

"ocaml" {>= "4.08"}

"host-system-msvc" {os = "win32"}

]

depopts: [

"lablgtk3" {>= "3.1.0"}

"ocamlfind"

This does not work. If I specify this, then opam simply uninstalls host-system-msys and installs host-system-msvc (at least on CI)...

jhjourdan · 2025-11-06T12:35:53Z

Thanks. I did that change, let's see how it goes.

jhjourdan · 2025-11-06T12:42:08Z

Cc @tleedjarv : again, I don't have a Windows machine at hand, and it looks like Unison refuses to build on the MinGW port. Since the build script explicitly mentions the MSVC port, I restricted Windows support to MSVC. Please tel me if this is ok with you.

jhjourdan · 2025-11-06T13:28:22Z

Alright, I tried to disable unison-gui entirely on Windows (because it just seems not to work on Windows), and enable unison on every Windows port (including MSVC, MinGW, etc...). Let's see what CI says.

jmid · 2025-11-06T13:32:38Z

packages/unison/unison.2.53.8/opam

+]
+conflicts: [
+  "lablgtk3" {os = "win32"}
+}


Suggested change

}

]

To address the parse error:

Warning: Could not read file D:\opamroot\repo\default\packages\unison\unison.2.53.8\opam. skipping: At D:\opamroot\repo\default\packages\unison\unison.2.53.8\opam:29:0-29:1:: Parse error

Thanks. Where do you get these lints?

(Somehow the "opam-ci" link disappeard for some time...)

Thanks. Where do you get these lints?

Click the Windows CI / build ... link
https://github.com/ocaml/opam-repository/actions/runs/19137212003/job/54692236076?pr=28851

then unfold the Install packages step

it is then written at the top:

<><> Updating package repositories ><><><><><><><><><><><><><><><><><><><><><><> [default] synchronised from file://D:/a/opam-repository/opam-repository Warning: Could not read file D:\opamroot\repo\default\packages\unison\unison.2.53.8\opam. skipping: At D:\opamroot\repo\default\packages\unison\unison.2.53.8\opam:29:0-29:1:: Parse error Now run 'opam upgrade' to apply any package updates. - Testing unison-gui.2.53.8 unison-gui.2.53.8 is not installable. Skip. - Testing unison.2.53.8 unison.2.53.8 is not installable. Skip.

You can further unfold the CI log for each individual package.
That's where I could see unison.2.53.8 building and unison-gui.2.53.8 failing.

This kind of error could also have been caught by running opam lint path/to/opam/file locally first (not pointing any fingers here - there's a reason I started sometimes remembering to do so... 😅 )

(Somehow the "opam-ci" link disappeard for some time...)

Yes, I've noticed too (both yesterday and today). I've notified @mtelvers

jmid · 2025-11-06T13:38:18Z

I'm not sure I understand the intent of limiting this to only MSVC on Windows.
From past CI logs the text-mode application unison seems to build under both Cygwin-MinGW and MSys2-MinGW (both using gcc I believe) - the GUI is another matter... 🤷
If the text-mode app compiles cleanly, then why disable it? 🤔

jhjourdan · 2025-11-06T13:40:03Z

From past CI logs the text-mode application unison seems to build under both Cygwin-MinGW and MSys2-MinGW

Well, apparently not.

jmid · 2025-11-06T14:19:52Z

Well, apparently not.

Perhaps I am misunderstanding something. On commit 591613f I see both Windows workflows building unison but failing to build unison-gui. This was using nmake for both and also listing host-system-msvc as a dependency. I also share your impression that the latter may not have had a great effect - for one it did not trigger a MSVC rebuild of the compiler.

Looking at the package description for host-system-msvc:

This package is installed if the underlying OCaml compiler is one of the "MSVC"
native Windows ports of OCaml.

Precisely, this means `ocamlopt -config-var system` is equal to either `win32`
or `win64`.

This package may be used in depends or conflicts fields of dependent packages
to indicate either a requirement or an incompatibility with this OCaml port.

I know from a self-PR that system: mingw64 for both our MinGW (Cygwin+MSys2) workflows. So that package may indeed be broken. Looking some more at its contents:

conflict-class: "ocaml-host-system"
available: os = "win32"

there doesn't seem to be much preventing it from installing on an existing setup with system: mingw64.

That being said, it still appears as if unison can build without MSVC... 🤔

jhjourdan · 2025-11-06T14:26:43Z

I posted a bug report on Unison for the build failure on MinGW: bcpierce00/unison#1164.

Let's see what happens. It may be the case that I have a quick answer...

jhjourdan · 2025-11-06T14:29:53Z

Appart from that, CI is failing under FreeBSD. The issue is caused by a fialure to build Cairo (the FreeBSD package, it seems). I am even less a FreeBSD user than a Windows user, so I don't want to debug this.

Should I leave the FreeBSD issue as is, or should I disable the GUI on FreeBSD? It seems to be more a FreeBSD issue than an Opam/Unison issue.

jmid · 2025-11-06T14:44:26Z

It is fine to leave FreeBSD as is. These days it is failing more often than succeeding, so I believe it is a CI issue.
Polite ping @mtelvers
https://opam.ci.ocaml.org/github/ocaml/opam-repository/commit/1f124b19b35c73f12d3cf39b2f82e4e50967093b/variant/freebsd,freebsd-14.3-ocaml-4.14-amd64,unison-gui.2.53.8

+ /usr/local/bin/sudo "pkg" "install" "-y" "graphics/cairo" "gtk3"
- Updating FreeBSD repository catalogue...
- pkg: An error occurred while fetching package: Unknown error
- pkg: An error occurred while fetching package: Unknown error
- pkg: An error occurred while fetching package: Unknown error
- pkg: An error occurred while fetching package: Unknown error
- pkg: An error occurred while fetching package: Unknown error
- Unable to update repository FreeBSD
- Updating FreeBSD-kmods repository catalogue...
- [rosemary] Fetching data.pkg: .. done
- pkg: No signature found
- FreeBSD-kmods repository is up to date.
- Error updating repositories!
- The following 82 package(s) will be affected (of 0 checked):
- 
- New packages to be INSTALLED:
- 	adwaita-icon-theme: 47.0 [FreeBSD]
- 	adwaita-icon-theme-legacy: 46.2 [FreeBSD]
- 	at-spi2-core: 2.56.4 [FreeBSD]
- 	avahi-app: 0.8_6 [FreeBSD]
- 	cairo: 1.18.2,3 [FreeBSD]
[...]
- 	xkeyboard-config: 2.41_4 [FreeBSD]
- 	xorgproto: 2024.1 [FreeBSD]
- 
- Number of packages to be installed: 82
- 
- The process will require 394 MiB more space.
- 67 MiB to be downloaded.
- [rosemary] [1/82] Fetching duktape-lib-2.7.0_1.pkg: ...
- .
- ...... done
- pkg: cached package duktape-lib-2.7.0_1: missing or size mismatch, fetching from remote
- [rosemary] [2/82] Fetching duktape-lib-2.7.0_1.pkg: ....
- .
- .... done
- pkg: cached package duktape-lib-2.7.0_1: missing or size mismatch, cannot continue
- Consider running 'pkg update -f'
- [rosemary] [3/82] Fetching duktape-lib-2.7.0_1.pkg: .
- ........ done
- pkg: cached package duktape-lib-2.7.0_1: missing or size mismatch, fetching from remote
- [rosemary] [4/82] Fetching duktape-lib-2.7.0_1.pkg: ..
- ...
- ..... done
- pkg: cached package duktape-lib-2.7.0_1: missing or size mismatch, cannot continue
- Consider running 'pkg update -f'
[ERROR] System package install failed with exit code 3 at command:
            sudo pkg install -y graphics/cairo gtk3
[ERROR] These packages are still missing: graphics/cairo gtk3

jhjourdan · 2025-11-06T15:13:54Z

Is it possible to get the log files of the opam build from the CI? I can get stdout/stderr from the CI, but the output is truncated by opam...

tleedjarv · 2025-11-06T15:52:02Z

Alright, I tried to disable unison-gui entirely on Windows (because it just seems not to work on Windows), and enable unison on every Windows port (including MSVC, MinGW, etc...). Let's see what CI says.

TUI/CLI (so unison) should build fine on all Windows ports. It's also possible to compile the GUI on all Windows ports but it requires some patching of the dependencies and/or may require some manual setup. You could see the upstream GHA workflow file for inspiration. The builds there use opam + make. I don't see why opam-only apporach wouldn't work just as well.

jhjourdan · 2025-11-06T15:52:36Z

I'm trying to patch the sources of Unison to see if that fixes the issue with Msys.

jhjourdan · 2025-11-06T16:57:46Z

I don't see why opam-only apporach wouldn't work just as well.

How should I patch the dependencies with an opam-only approach? I can apply a patch to unison, but I don't see how I could apply a patch to e.g., Cairo.

tleedjarv · 2025-11-06T18:42:22Z

I don't see why opam-only apporach wouldn't work just as well.

How should I patch the dependencies with an opam-only approach? I can apply a patch to unison, but I don't see how I could apply a patch to e.g., Cairo.

Right, maybe you can't.
Maybe then the patches can be incorporated to the relevant packages directly. Here are the tickets:
Chris00/ocaml-cairo#39
garrigue/lablgtk#165 (comment)
I don't see ocaml-cairo or lablgtk3 getting any new releases, so the patching would have to be done within opam-repository, I guess (I don't know how it works).

jhjourdan · 2025-11-06T22:36:42Z

I opened actual PRs for these two issues. Let's see if the maintainers don't react.

My problems with patching in the opam package is that 1- they have not been validated and thoroughly tested in other platforms than Windows and 2- I don't know where to host the patches.

jhjourdan · 2025-11-06T22:51:23Z

Ok, so I replaced the patch with bcpierce00/unison#1166, which should fix the issue on Windows.

jhjourdan · 2025-11-06T22:53:49Z

That's ready to merge.

jhjourdan · 2025-11-07T07:26:32Z

Actually, hold on: @gdt wants to do some cosmetic changes on the patch, and the hashes will change...

jhjourdan force-pushed the unison_release branch from dfb5611 to 7165ff4 Compare November 5, 2025 20:06

mseri added the consider for merge label Nov 5, 2025

kit-ty-kate reviewed Nov 6, 2025

View reviewed changes

jhjourdan force-pushed the unison_release branch from 7165ff4 to 591613f Compare November 6, 2025 12:35

jhjourdan force-pushed the unison_release branch from 591613f to 2548201 Compare November 6, 2025 13:26

jmid reviewed Nov 6, 2025

View reviewed changes

jhjourdan force-pushed the unison_release branch from 2548201 to 359bde1 Compare November 6, 2025 13:34

jhjourdan force-pushed the unison_release branch from 359bde1 to 1f124b1 Compare November 6, 2025 13:41

jhjourdan changed the title ~~Unison 2.53.8.~~ [Draft] Unison 2.53.8. Nov 6, 2025

jhjourdan changed the title ~~[Draft] Unison 2.53.8.~~ Unison 2.53.8. Nov 6, 2025

jhjourdan marked this pull request as draft November 6, 2025 15:52

jhjourdan force-pushed the unison_release branch from 47f7f66 to 519dfcd Compare November 6, 2025 16:03

jhjourdan force-pushed the unison_release branch from 519dfcd to 910a454 Compare November 6, 2025 22:47

jhjourdan marked this pull request as ready for review November 6, 2025 22:48

Unison 2.53.8.

2afebf5

jhjourdan force-pushed the unison_release branch from 910a454 to 2afebf5 Compare November 6, 2025 23:06

jhjourdan mentioned this pull request Nov 7, 2025

Fix compilation on MSYS2 bcpierce00/unison#1166

Open

Unison 2.53.8. #28851

Are you sure you want to change the base?

Unison 2.53.8. #28851

Conversation

jhjourdan commented Nov 5, 2025

Uh oh!

jhjourdan commented Nov 5, 2025

Uh oh!

mseri commented Nov 5, 2025

Uh oh!

jmid commented Nov 5, 2025

Uh oh!

jhjourdan commented Nov 5, 2025

Uh oh!

jhjourdan commented Nov 5, 2025

Uh oh!

mseri commented Nov 5, 2025

Uh oh!

jmid commented Nov 6, 2025

Uh oh!

mseri commented Nov 6, 2025

Uh oh!

kit-ty-kate commented Nov 6, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jhjourdan commented Nov 6, 2025

Uh oh!

jhjourdan commented Nov 6, 2025

Uh oh!

jhjourdan commented Nov 6, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jmid commented Nov 6, 2025

Uh oh!

jhjourdan commented Nov 6, 2025

Uh oh!

jmid commented Nov 6, 2025

Uh oh!

jhjourdan commented Nov 6, 2025

Uh oh!

jhjourdan commented Nov 6, 2025

Uh oh!

jmid commented Nov 6, 2025

Uh oh!

jhjourdan commented Nov 6, 2025

Uh oh!

tleedjarv commented Nov 6, 2025

Uh oh!

jhjourdan commented Nov 6, 2025

Uh oh!

jhjourdan commented Nov 6, 2025

Uh oh!

tleedjarv commented Nov 6, 2025

Uh oh!

jhjourdan commented Nov 6, 2025

Uh oh!

jhjourdan commented Nov 6, 2025

Uh oh!

jhjourdan commented Nov 6, 2025

Uh oh!

jhjourdan commented Nov 7, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects