Stream: Coq devs & plugin devs

Topic: CoqIDE configuration recently broken?


view this post on Zulip Jason Gross (Mar 09 2022 at 23:03):

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?

view this post on Zulip Gaëtan Gilbert (Mar 10 2022 at 00:08):

we haven't changed configure for 3 months according to https://github.com/coq/coq/tree/master/tools

view this post on Zulip Jason Gross (Mar 10 2022 at 04:55):

Hm, on March 4 the log says

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

view this post on Zulip Jason Gross (Mar 10 2022 at 05:06):

Reported as https://bugs.launchpad.net/ubuntu/+source/lablgtk3/+bug/1964437

view this post on Zulip Jason Gross (Mar 10 2022 at 05:06):

Maybe there should be a way to override unspecified version failures?

view this post on Zulip Guillaume Melquiond (Mar 10 2022 at 06:08):

There is nothing new. This is the same bug (Dune's feature) as before. The source code does not contain the version number.

view this post on Zulip Guillaume Melquiond (Mar 10 2022 at 06:12):

And this time, we cannot even blame Debian's maintainers, since there are no upstream tarballs other than Github's autogenereated ones.

view this post on Zulip Guillaume Melquiond (Mar 10 2022 at 06:21):

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.

view this post on Zulip Théo Zimmermann (Mar 10 2022 at 09:08):

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.

view this post on Zulip Emilio Jesús Gallego Arias (Mar 10 2022 at 09:22):

Dune doesn't handle versioning, so I am not sure how lablgtk maintainers were using it for that.

view this post on Zulip Théo Zimmermann (Mar 10 2022 at 09:40):

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.

view this post on Zulip Théo Zimmermann (Mar 10 2022 at 09:41):

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.

view this post on Zulip Emilio Jesús Gallego Arias (Mar 10 2022 at 09:42):

That's dune-release indeed, not dune

view this post on Zulip Emilio Jesús Gallego Arias (Mar 10 2022 at 09:43):

that's what I meant

view this post on Zulip Emilio Jesús Gallego Arias (Mar 10 2022 at 09:43):

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

view this post on Zulip Emilio Jesús Gallego Arias (Mar 10 2022 at 09:43):

dune has no mechanism to control versions / releases (yet)

view this post on Zulip Emilio Jesús Gallego Arias (Mar 10 2022 at 09:43):

would be nice if it did


Last updated: Feb 05 2023 at 20:03 UTC