[PATCH gnome-team 0/1] Fix opam on gnome-team

  • Open
  • quality assurance status badge
Details
4 participants
  • Julien Lepiller
  • Liliana Marie Prikler
  • Maxim Cournoyer
  • Vivien Kraus
Owner
unassigned
Submitted by
Vivien Kraus
Severity
normal
V
V
Vivien Kraus wrote on 9 Mar 13:08 +0100
(address . guix-patches@gnu.org)
cover.1709986125.git.vivien@planete-kraus.eu
Dear Guix,

For some unknown reason, opam on master decides that the ocaml base64 library
is not installed well enough to use it, but on gnome-team, it seems that it
does.

Opam can adapt to both cases, by using a different compatibility layer in
each. On master, it uses the compatibility layer version 5, and on
gnome-team, the compatibility layer version 6.

However, the compatibility layer version 6 does not work. An easy fix is to
force opam to use compatibility layer version 5 every time.

I am not proud of my regular expressions, but I couldn’t find a way to
factorize the optional `i` so that it matches either .ml or .mli.

Best regards,

Vivien

Vivien Kraus (1):
gnu: opam: Fix build.

gnu/packages/ocaml.scm | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)


base-commit: 25c14c893f05019d746321285acf55d1aa65b943
--
2.41.0
V
V
Vivien Kraus wrote on 9 Mar 10:46 +0100
[PATCH gnome-team 1/1] gnu: opam: Fix build.
(address . 69677@debbugs.gnu.org)
3a4e1befc3e3da925fccec1d88f53fff1ffff83b.1709986125.git.vivien@planete-kraus.eu
* gnu/packages/ocaml.scm (ocaml-opam-core) [#:phases]: Add 'always-use-base64-compat-5'.

Change-Id: I8d9aec14ca2af92b9a4ac346ac57c22e6b76c716
---
Sorry, I messed up my cover letter, so it was not delivered to you.

Here it is:

Dear Guix,

For some unknown reason, opam on master decides that the ocaml base64 library
is not installed well enough to use it, but on gnome-team, it seems that it
does.

Opam can adapt to both cases, by using a different compatibility layer in
each. On master, it uses the compatibility layer version 5, and on
gnome-team, the compatibility layer version 6.

However, the compatibility layer version 6 does not work. An easy fix is to
force opam to use compatibility layer version 5 every time.

I am not proud of my regular expressions, but I couldn’t find a way to
factorize the optional `i` so that it matches either .ml or .mli.

Best regards,

Vivien

gnu/packages/ocaml.scm | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)

Toggle diff (33 lines)
diff --git a/gnu/packages/ocaml.scm b/gnu/packages/ocaml.scm
index 0f4c351141..5051524a53 100644
--- a/gnu/packages/ocaml.scm
+++ b/gnu/packages/ocaml.scm
@@ -854,6 +854,26 @@ (define ocaml-opam-core
#:tests? #f
#:phases
(modify-phases %standard-phases
+ (add-after 'unpack 'always-use-base64-compat-5
+ (lambda _
+ (call-with-input-file "src/client/dune"
+ (lambda (port)
+ (display "ok")
+ (newline)))
+ ;; By default, the opamBase64Compat module will be
+ ;; compatibility version 6, which is just an empty
+ ;; file. Opam-client cannot build with an empty file.
+ (substitute* "src/client/dune"
+ (("opamBase64Compat\\.ml\\.6")
+ "opamBase64Compat.ml.5")
+ (("opamBase64Compat\\.mli\\.6")
+ "opamBase64Compat.mli.5")
+ ;; Undo the change in the rule to generate the .6
+ ;; files
+ (("with-stdout-to opamBase64Compat\\.ml\\.5")
+ "with-stdout-to opamBase64Compat.ml.6")
+ (("with-stdout-to opamBase64Compat\\.mli\\.5")
+ "with-stdout-to opamBase64Compat.mli.6"))))
(add-before 'build 'pre-build
(lambda* (#:key inputs make-flags #:allow-other-keys)
(let ((bash (assoc-ref inputs "bash"))
--
2.41.0
M
M
Maxim Cournoyer wrote on 9 Mar 19:18 +0100
(name . Vivien Kraus)(address . vivien@planete-kraus.eu)
87y1are0a8.fsf@gmail.com
Hi Vivien,

Vivien Kraus <vivien@planete-kraus.eu> writes:

Toggle quote (2 lines)
> * gnu/packages/ocaml.scm (ocaml-opam-core) [#:phases]: Add 'always-use-base64-compat-5'.

[...]

Toggle quote (18 lines)
> gnu/packages/ocaml.scm | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/gnu/packages/ocaml.scm b/gnu/packages/ocaml.scm
> index 0f4c351141..5051524a53 100644
> --- a/gnu/packages/ocaml.scm
> +++ b/gnu/packages/ocaml.scm
> @@ -854,6 +854,26 @@ (define ocaml-opam-core
> #:tests? #f
> #:phases
> (modify-phases %standard-phases
> + (add-after 'unpack 'always-use-base64-compat-5
> + (lambda _
> + (call-with-input-file "src/client/dune"
> + (lambda (port)
> + (display "ok")
> + (newline)))

Shouldn't this be 'call-with-output-file' ? It seems you want to
*write* a file containing "ok\n".

Toggle quote (5 lines)
> + ;; By default, the opamBase64Compat module will be
> + ;; compatibility version 6, which is just an empty
> + ;; file. Opam-client cannot build with an
> empty file.

What does upstream say about this? Is this a bug? Or some understood
limitation they don't foresee fixing?

Toggle quote (12 lines)
> + (substitute* "src/client/dune"
> + (("opamBase64Compat\\.ml\\.6")
> + "opamBase64Compat.ml.5")
> + (("opamBase64Compat\\.mli\\.6")
> + "opamBase64Compat.mli.5")
> + ;; Undo the change in the rule to generate the .6
> + ;; files
> + (("with-stdout-to opamBase64Compat\\.ml\\.5")
> + "with-stdout-to opamBase64Compat.ml.6")
> + (("with-stdout-to opamBase64Compat\\.mli\\.5")
> + "with-stdout-to opamBase64Compat.mli.6"))))

I'd like to hear about upstream. Perhaps our package is simply buggy?
It'd be nice to have an upstream issue to link to.

--
Thanks,
Maxim
V
V
Vivien Kraus wrote on 9 Mar 19:21 +0100
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
878300fe0b9a90985e65ebc49e65eae7809d6944.camel@planete-kraus.eu
Le samedi 09 mars 2024 à 13:18 -0500, Maxim Cournoyer a écrit :
Toggle quote (2 lines)
> Shouldn't this be 'call-with-output-file' ?  It seems you want to
> *write* a file containing "ok\n".
Oops, I forgot to remove that, how embarrassing. Sorry.
V
V
Vivien Kraus wrote on 9 Mar 20:39 +0100
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
6052b863f74d183b2088db53ce85f41c6e1a247f.camel@planete-kraus.eu
Le samedi 09 mars 2024 à 13:18 -0500, Maxim Cournoyer a écrit :
Toggle quote (4 lines)
>
> I'd like to hear about upstream.  Perhaps our package is simply
> buggy?
> It'd be nice to have an upstream issue to link to.
With a closer investigation, it looks lik we are doing things wrong
indeed.

From within the failed build directory, if I set up the environment
variable, run ocaml -I <the bunch of include directories>, and in the
prompt, run:

#load "base64.cma";;
Base64.decode_exn;;

I get an error message:

Error: The files /gnu/store/wh2ipi0bjywcf5pyis6z1s52adf5cqyd-ocaml-
base64-3.5.1/lib/ocaml/site-lib/base64/base64.cma
and /gnu/store/i01v0c5yzhw62qmvrlv3y436igwhcafh-ocaml-extlib-
1.7.9/lib/ocaml/site-lib/extlib/base64.cmi
make inconsistent assumptions over interface Base64

My guess is that we have 2 ocaml libraries implementing Base64 (ocaml-
base64 and ocaml-extlib, propagated from ocaml-dose3). Dune sees that
we have a powerful ocaml-base64 installed, so it lays out the
compatibility version 6 for us, but when it comes to actually building
the project, ocamlfind prioritizes the ocaml-extlib path by adding it
first, and it shadows our powerful ocaml-base64 implementation.

With this new extlib actor in the plot, I could search better. It
seems like Opam is aware of the issue:


The solution seems to be for extlib to ship a minimal version. But
maybe this should primarily concern the ocaml team, not gnome-team, as
it looks to me like a recipe for breaking at least half of the ocaml
ecosystem.

Best regards,

Vivien
L
L
Liliana Marie Prikler wrote on 9 Mar 21:35 +0100
a5577e01bd7e3a31ab185229e6aa34d8eaeb2328.camel@gmail.com
Hi Vivien,

Am Samstag, dem 09.03.2024 um 20:39 +0100 schrieb Vivien Kraus:
Toggle quote (17 lines)
> My guess is that we have 2 ocaml libraries implementing Base64
> (ocaml-base64 and ocaml-extlib, propagated from ocaml-dose3). Dune
> sees that we have a powerful ocaml-base64 installed, so it lays out
> the compatibility version 6 for us, but when it comes to actually
> building the project, ocamlfind prioritizes the ocaml-extlib path by
> adding it first, and it shadows our powerful ocaml-base64
> implementation.
>
> With this new extlib actor in the plot, I could search better.  It
> seems like Opam is aware of the issue:
>
> https://github.com/ocaml/opam/issues/5694
>
> The solution seems to be for extlib to ship a minimal version. But
> maybe this should primarily concern the ocaml team, not gnome-team,
> as it looks to me like a recipe for breaking at least half of the
> ocaml ecosystem.
How much of it is broken with gnome-team already (vs. broken on other
branches)? It wouldn't be nice of us to say "here, we broke it, you
fix it please". It also appears as though opam only has two dependants
– are we not tracking this correctly or is a minimal version in use
anyway?

Cheers
V
V
Vivien Kraus wrote on 9 Mar 22:29 +0100
a9c5fd023074f597736464ae20c20c704b0fe868.camel@planete-kraus.eu
Le samedi 09 mars 2024 à 21:35 +0100, Liliana Marie Prikler a écrit :
Toggle quote (11 lines)
> > The solution seems to be for extlib to ship a minimal version. But
> > maybe this should primarily concern the ocaml team, not gnome-team,
> > as it looks to me like a recipe for breaking at least half of the
> > ocaml ecosystem.
> How much of it is broken with gnome-team already (vs. broken on other
> branches)?  It wouldn't be nice of us to say "here, we broke it, you
> fix it please".  It also appears as though opam only has two
> dependants
> – are we not tracking this correctly or is a minimal version in use
> anyway?

I meant that the fix should maybe be proposed to the OCaml team, not
the GNOME team. I also over-estimated the number of packages that
depend on ocaml-extlib, so it is probably safe.

I opened #69682 for this.

Best regards,

Vivien
J
J
Julien Lepiller wrote on 9 Mar 22:35 +0100
Re: [bug#69677] [PATCH gnome-team 1/1] gnu: opam: Fix build.
A2836F66-8014-4CAA-9585-520FAB5899B2@lepiller.eu
Le 9 mars 2024 21:35:43 GMT+01:00, Liliana Marie Prikler <liliana.prikler@gmail.com> a écrit :
Toggle quote (21 lines)
>Hi Vivien,
>
>Am Samstag, dem 09.03.2024 um 20:39 +0100 schrieb Vivien Kraus:
>> My guess is that we have 2 ocaml libraries implementing Base64
>> (ocaml-base64 and ocaml-extlib, propagated from ocaml-dose3). Dune
>> sees that we have a powerful ocaml-base64 installed, so it lays out
>> the compatibility version 6 for us, but when it comes to actually
>> building the project, ocamlfind prioritizes the ocaml-extlib path by
>> adding it first, and it shadows our powerful ocaml-base64
>> implementation.
>>
>> With this new extlib actor in the plot, I could search better.  It
>> seems like Opam is aware of the issue:
>>
>> https://github.com/ocaml/opam/issues/5694
>>
>> The solution seems to be for extlib to ship a minimal version. But
>> maybe this should primarily concern the ocaml team, not gnome-team,
>> as it looks to me like a recipe for breaking at least half of the
>> ocaml ecosystem.

Sounds like we could switch extlib to the dune build-system, possibly adding a #:package argument to make sure it doesn't build the compat version.

Toggle quote (6 lines)
>How much of it is broken with gnome-team already (vs. broken on other
>branches)? It wouldn't be nice of us to say "here, we broke it, you
>fix it please". It also appears as though opam only has two dependants
>– are we not tracking this correctly or is a minimal version in use
>anyway?

opam is not used to build ocaml packages, so it's not a surprise to me it has so few dependents. Would be nice not to break it though, it's still a useful program by itself :)

Toggle quote (5 lines)
>
>Cheers
>
>
>
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 69677@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 69677
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch