guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#57540] [PATCH] Please rebase (was: Add ocaml-elpi (a dependency of


From: Julien Lepiller
Subject: [bug#57540] [PATCH] Please rebase (was: Add ocaml-elpi (a dependency of coq-mathcomp-analysis))
Date: Thu, 29 Sep 2022 19:39:22 +0200
User-agent: K-9 Mail for Android

You can close by sending a reply to nnnnn-close@debbugs.gnu.org, where nnnnn is the bug number. If it's easier for you, let's focus on ocaml-elpi first :)

If you have any question or need help, don't hesitate to ask!

Le 29 septembre 2022 19:13:25 GMT+02:00, Garek Dyszel <garekdyszel@disroot.org> a écrit :
Hi again,

It looks like Coq has been updated to 8.16 now, which means the two
packages required by coq-mathcomp-hierarchy-builder in this patchset are
now out of date. The build processes have completely changed for
ocaml-elpi and coq-elpi.

The new ocaml-elpi build system got rather confusing and will likely
take me much longer than I originally expected. Maybe we could close
this issue? I think it might be easier if I were to send in ocaml-elpi
on its own, for example.

Let me know.

Thanks!
Garek

At 09:04 2022-09-27 UTC-0400, Garek Dyszel <garekdyszel@disroot.org> wrote:
Hi Julien and simon,

I planned to write back yesterday but had to run out the door
unexpectedly.

At 18:52 2022-09-26 UTC+0200, zimoun <zimon.toutoune@gmail.com> wrote:
For instance the series reads, ... where the logic about the order is
not obvious

The logic was essentially adding dependencies in reverse order. I
started with the package that I wanted to build (coq-mathcomp-analysis),
and added the dependencies as I found they were needed.

I'll stick with committing dependencies in forward order (committing
dependencies before packages) from now on.

I have tried to clean the mess but I give up for now. :-) It would be
much easier if the series provides,

1. the Git commit against which revision these patches apply (see the
option --base of git-format-patch)

2. the correct dependency order of the patches

Probably it would also be easier to start over from the new master
branch and recommit the remaining packages in the proper order.

If I don't have another major interruption, I will send out a new set of
commits, in the correct order, formatted with --base, before or by
Friday. Excluding those packages which were already pushed to master, of
course :)

At 20:39 2022-09-24 UTC+0200, Julien Lepiller <julien@lepiller.eu> wrote:
No need to repeat the license here. Also, this means that the license
should be lgpl2.1+, instead of plain lgpl2.1.

Ah, seems like I was getting lost in package-ception there and didn't
check over the descriptions too rigorously. I'll keep this in mind when
preparing the next patchset for this thread.

For python packages, I see you add python to the inputs. Why is that?
The python-build-system already provides python.

I had been getting errors of the form "python3 was not found on the
PATH" during the 'configure' phase of some python packages, even though
the python-build-system was being used. I added python to everything to
avoid such errors, but forgot to remove it for packages where it was not
really needed.

If I can find the first package that produced that error, I'll submit a
bug report for it with the precise error quoted.

It looks like python-jsonschema-next (4.5.1) does not have any
dependent, so updating this package instead might be better than
adding a new one, wdyt?

I found evidence to the contrary, I think. With graphviz installed, I
ran

$ guix graph python-jsonschema > /tmp/py-js-deps.dot
$ gc -n /tmp/py-js-deps.dot

which says that there are 186 nodes, or (186 - 1) = 185 packages
dependent on python-jsonschema-next. If you prefer viewing it as an
image,

$ dot /tmp/py-js-deps.dot > /tmp/py-js-deps.png
$ feh /tmp/py-js-deps.png

shows all 185 packages originating from the node named
"python-jsonschema@4.5.1".

Maybe for now we could add this transitional python-jsonschema-4.15 to
build coq-mathcomp-analysis, and remove it in a subsequent patchset? I
don't want to tie this patch up unnecessarily.

If I have malformed patches now with only 20 packages,... well, let's
just say I don't know if I want to see the results just yet, if I'll
need to rebuild 185 :)

-- Garek

reply via email to

[Prev in Thread] Current Thread [Next in Thread]