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-09T19:41:56Z

You can have more control, should it help rewrite the opam packages. The GUI is automatically built only for the default target, which means "build everything" (also spelled all). If you don't want the GUI built then you specify only the wanted targets (in this case, tui fsmonitor). Likewise, you can have only the GUI built (by specifying gui as the target).

Interesting. Did this change recently? I remember from packaging the previous versions that this was not possible easily.

Also, does this work with nmake?

And what about the installed files? Does make install install only the target that has been built? Is there an intersection between the files installed after make gui and those installed after make tui?

Now, the problem is that [...] Unison's GUI is incompatible with Windows when using Opam.

This is not correct, strictly speaking. I believe the point was that the issues are not with the Unison's package specifically but with respective upstreams:

Unison-gui needs some OCamlfind patches to be built using Msys

Unison-gui needs some patches onto lablgtk+cairo to be built using MSVC

We can have a debate about what "incompatible" means in this context, but the end result is that opam install unison-gui would fail on Windows. And, except if Ocamlfind's bug is fixed very quickly, I prefer this "incompatibility" to be documented as part of the package.

Now, well, if @dra27 or the maintainers of the repo tell me to do otherwise, I will comply, of course.

tleedjarv · 2025-11-09T20:13:56Z

Interesting. Did this change recently? I remember from packaging the previous versions that this was not possible easily.

Should have been since 2.53.4. I'm not sure why it hasn't been brought up earlier.

Also, does this work with nmake?

It should, yes. If it doesn't then it's a bug.

And what about the installed files? Does make install install only the target that has been built? Is there an intersection between the files installed after make gui and those installed after make tui?

Installs only the built files (otherwise it's a bug). There is currently no intersection between these targets. Shared between those are optional targets of fsmonitor and manpage (built with target manpage and also with docs).

jhjourdan · 2025-11-13T19:28:10Z

I've just pushed a new version witch:

Incorporates @dra27's remarks
Uses specific targets to build the TUI and the GUI separately instead of the hack we were using before. Seems to work well.

@dra27 are you satisfied with this new version?

jhjourdan · 2025-11-13T19:31:37Z

I also make sure that the native MacOS GUI is built on that system, but this fails on CI because xcode is not installed. I guess this is not an issue for merging?

tleedjarv · 2025-11-13T19:58:24Z

No need to build manpage with NMAKE. Building manpage requires POSIX tools; it was considered that manpage is not needed in Windows anyway.

About the native macOS GUI. I don't know which GUI is more used or preferred by Mac users, but it is relevant to know that the native GUI is currently more or less unmaintained and at some point may deteriorate quickly with little notice.

jhjourdan · 2025-11-13T22:39:26Z

Fair enough. I fixed both the macos and the nmake issues.

jmid

The present version LGTM 👍
Thanks for the extra effort to get things running nicely on Windows too!

Would you consider adding x-maintenance-intent entries?
https://github.com/ocaml/opam-repository/blob/master/governance/policies/archiving.md

packages/unison-gui/unison-gui.2.53.8/opam

jhjourdan · 2025-11-17T22:09:08Z

So now MSYS2 CI fails because of lablgtk...

mseri · 2025-11-18T09:30:26Z

That's all right imo. If and when lablgtk or other dependencies are fixed, we will see if this works or not. But I'd give it the benefit of doubt: we don't normally block a merge on an independent dependency that fails to install in the CI

mseri · 2025-11-18T09:31:43Z

Thanks a lot for all the effort. Github does not allow me to merge until @dra27 explicitly approves the PR though

dra27

I'm pre-stamping an approval to lift my "changes" block - just one last little change. With #28918, this should finally pass the MSYS2 CI!

packages/unison/unison.2.53.8/opam

jhjourdan · 2025-11-18T17:20:13Z

Great! Many thanks, @dra27, to take care of this, and being (positively) so picky about details. This is thanks to that that we get high-quality support of OCaml for Windows. I really appreciate that, and I think Unison developpers (@tleedjarv) apreciate that too!

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

jmid mentioned this pull request Nov 10, 2025

Teach x-ci-accept-failures to Windows CI tests #28856

Open

jhjourdan force-pushed the unison_release branch 4 times, most recently from 228eb2e to 8f66b26 Compare November 13, 2025 19:22

jhjourdan force-pushed the unison_release branch 2 times, most recently from 4f83f4b to b482874 Compare November 13, 2025 19:32

jhjourdan force-pushed the unison_release branch from b482874 to 721845d Compare November 13, 2025 22:38

jhjourdan force-pushed the unison_release branch from 721845d to 9d89aa3 Compare November 13, 2025 22:54

jmid approved these changes Nov 14, 2025

View reviewed changes

jmid added question consider for merge and removed do not merge labels Nov 14, 2025

dra27 reviewed Nov 15, 2025

View reviewed changes

packages/unison-gui/unison-gui.2.53.8/opam Outdated Show resolved Hide resolved

jhjourdan force-pushed the unison_release branch from 9d89aa3 to e42dce3 Compare November 17, 2025 20:42

mseri approved these changes Nov 18, 2025

View reviewed changes

dra27 mentioned this pull request Nov 18, 2025

Hotfixes for labgtk3 for Windows #28918

Open

dra27 approved these changes Nov 18, 2025

View reviewed changes

packages/unison/unison.2.53.8/opam Show resolved Hide resolved

Unison 2.53.8.

b8c8db0

jhjourdan force-pushed the unison_release branch from e42dce3 to b8c8db0 Compare November 18, 2025 17:17

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 9, 2025

Uh oh!

tleedjarv commented Nov 9, 2025

Uh oh!

jhjourdan commented Nov 13, 2025

Uh oh!

jhjourdan commented Nov 13, 2025

Uh oh!

tleedjarv commented Nov 13, 2025

Uh oh!

jhjourdan commented Nov 13, 2025

Uh oh!

jmid left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

jhjourdan commented Nov 17, 2025

jmid left a comment •

edited

Loading