As of yesterday(?), I'm getting errors because configure is misdetecting lablgtk. See, e.g., https://launchpadlibrarian.net/589689507/buildlog_ubuntu-jammy-amd64.coq_8.master~git~202203082103+23112-0~daily375-a0df849836~ubuntu22.04.1_BUILDING.txt.gz , where CoqIDE fails to build with
LablGtk3 and LablGtkSourceView3 found ([unspecified]), but too old (required >= 3.1.0, found [unspecified]):
=> no CoqIDE will be built.
despite me using 3.1.2-1
Is this a deliberate / known change?
we haven't changed configure for 3 months according to https://github.com/coq/coq/tree/master/tools
LablGtk3 and LablGtkSourceView3 found (3.1.1), with native threads:
=> native CoqIDE will be built.
while on March 8 the log says
LablGtk3 and LablGtkSourceView3 found ([unspecified]), but too old (required >= 3.1.0, found [unspecified]):
=> no CoqIDE will be built.
Hm, I guess the issue is that liblablgtk3-ocaml, liblablgtksourceview3-ocaml, liblablgtk3-ocaml-dev, and liblablgtksourceview3-ocaml-dev got upgraded from 3.1.1+official-1build2 to 3.1.2-1? (There was also an upgrade from linux-libc-dev_5.15.0-18.18 to linux-libc-dev_5.15.0-22.22 , but this seems like not a likely culprit.)
Reported as https://bugs.launchpad.net/ubuntu/+source/lablgtk3/+bug/1964437
Maybe there should be a way to override unspecified version failures?
There is nothing new. This is the same bug (Dune's feature) as before. The source code does not contain the version number.
And this time, we cannot even blame Debian's maintainers, since there are no upstream tarballs other than Github's autogenereated ones.
The good news is that Lablgtk's maintainers have finally learned their lesson this time; they will no longer use Dune to handle versioning. But obviously, this change will not be visible until the next release of Lablgtk.
Indeed, FTR the package needed a patch to correctly output the version number in opam and in nixpkgs. See: https://github.com/NixOS/nixpkgs/pull/155871/files. You can certainly recommend applying the same patch to the Debian package.
Dune doesn't handle versioning, so I am not sure how lablgtk maintainers were using it for that.
Projects that use dune-release are known to report their version correctly only when the proper .tbz
archive was used instead of the auto-generated GitHub one.
I don't know any more details because I've only seen the issue (multiple times) from the packager point of view but I have never used dune-release myself.
That's dune-release indeed, not dune
that's what I meant
fully automated release is not easy in my experience, but I'm sure dune-release devs would add a warning for that case if we submit an issue
dune has no mechanism to control versions / releases (yet)
would be nice if it did
Last updated: Sep 30 2023 at 16:01 UTC