Installing in-progress opam project

Learning
21

I’m using opam 2.4.1.
I’ve already put a message here, though I’m not sure it’s the right place.

I’ve been trying to debug a bit on my side because the report would be pretty light right now. I think it might actually be a segfault in git?

┬─[sacha@SachaMBP:~/P/soteria]─[14:58:33]─[G:cbmc =]
╰─>$ opam reinstall soteria-c --switch=bfa-install --working-dir -v -v
+ /usr/bin/sw_vers "-productVersion"
- 15.5
+ /Users/sacha/.opam/bfa-install/bin/ocamlc "-vnum"
- 5.3.0
+ /bin/sh "-c" "ocamlc -config 2>/dev/null | tr -d '\\r' | sed -n -e 's/^os_type: Win32/msvc/p;s/^os_type: .*/libc/p'"
- libc

<><> Synchronising pinned packages ><><><><><><><><><><><><><><><><><><><><>  🐫 
+ /usr/bin/git "clean" "-fdx" (CWD=/Users/sacha/.opam/bfa-install/.opam-switch/sources/soteria-c)
+ /usr/bin/git "remote" "set-url" "origin" "file:///Users/sacha/Prog/soteria" (CWD=/Users/sacha/.opam/bfa-install/.opam-switch/sources/soteria-c)
+ /usr/bin/git "fetch" "-q" "file:///Users/sacha/Prog/soteria" "--update-shallow" "+cbmc:refs/remotes/opam-ref-cbmc" (CWD=/Users/sacha/.opam/bfa-install/.opam-switch/sources/soteria-c)
+ /usr/bin/git "diff" "--no-ext-diff" "--quiet" "refs/remotes/opam-ref-cbmc" "--" (CWD=/Users/sacha/.opam/bfa-install/.opam-switch/sources/soteria-c)
Processing  1/1: [soteria-c.dev: git]fish: Job 1, 'opam reinstall soteria-c --swit…' terminated by signal SIGSEGV (Address boundary error)

I’m not sure it would be reproducible anywhere else

22

Hmm, running that last command manually doesn’t segfault so maybe it’s an opam bug, I’ll signal it but not quite sure how to reproduce on other laptops

23

Fun fact, I tried reproducing it.

I cloned a fresh repo, created a fresh switch with the same invariant. Installed the same git version. Then did some modifications and tried to reinstall with --working-dir. I don’t get a segfault but I get:

[ERROR] The compilation of soteria-c.dev failed at "dune build -p soteria-c -j 15
        --promote-install-files=false @install"

# Error: The package soteria-c does not have any user defined stanzas attached
# to it. If this is intentional, add (allow_empty) to the package definition in
# the dune-project file
# -> required by _build/default/soteria-c.install
# -> required by alias install

Even though running

dune build -p soteria-c -j 15 --promote-install-files=false @install

works perfectly fine. I also have several dune files with library or executable stanzas that contain (package soteria-c).
The only diff is that I added some let () = failwith "" at the end of the main executable of the package to check if it would crash as expected after installation.

I’ve submitted an issue but I don’t even know if that one is reproducible (or if it’s even a bug)

24

This isn’t since it doesn’t point to the segfault you experienced but talks about another subject (the default behaviour of opam pin).

Could you try running opam reinstall soteria-c --switch=bfa-install --working-dir --debug-level=3 and paste here the relevant bit at the end (last handful of lines)?

25

Sorry, the message I put points to @dbuenzli’s comment, unrelated to the segfault

26

For the segfault issue, here is the result of --debug-level=3

00:01.006  UPDATE                 updating git+file:///Users/sacha/Prog/soteria#cbmc
00:01.006  SYSTEM                 mkdir /private/var/folders/zw/pnw89cw53s55ssszz27_0xh00000gn/T/opam-6346-a11e0b
00:01.006  PARALLEL               Next task in job 0: /usr/bin/git clean -fdx
Processing  1/1: [soteria-c.dev: git]
00:01.151  PARALLEL               GC compact (heap 176 MB -> 176 MB)
00:01.151  PARALLEL               Collected task for job 0 (ret:0)
00:01.151  PARALLEL               Next task in job 0: /usr/bin/git remote set-url origin file:///Users/sacha/Prog/soteria
00:01.160  PARALLEL               Collected task for job 0 (ret:0)
00:01.160  PARALLEL               Next task in job 0: /usr/bin/git fetch -q file:///Users/sacha/Prog/soteria --update-shallow +cbmc:refs/remotes/opam-ref-cbmc
00:01.179  PARALLEL               Collected task for job 0 (ret:0)
00:01.179  PROC                   safe_unlink: /Users/sacha/.opam/log/log-6346-df49a8.info
00:01.179  PROC                   safe_unlink: /Users/sacha/.opam/log/log-6346-df49a8.env
00:01.179  PROC                   safe_unlink: /Users/sacha/.opam/log/log-6346-df49a8.out
00:01.179  PARALLEL               Next task in job 0: /usr/bin/git diff --no-ext-diff --quiet refs/remotes/opam-ref-cbmc --
00:01.187  PARALLEL               Collected task for job 0 (ret:0)
00:01.187  PARALLEL               Next task in job 0: /usr/bin/git ls-files
00:01.194  PARALLEL               Collected task for job 0 (ret:0)
00:01.194  PARALLEL               Next task in job 0: /usr/bin/git status --short
00:01.204  PARALLEL               Collected task for job 0 (ret:0)
fish: Job 1, 'opam reinstall soteria-c --swit…' terminated by signal SIGSEGV (Address boundary error)
27

The OP seems to be wanting to use opam as a development-time tool: to install interim versions of code, modify, then repeat. But this is what a build-system is for, and opam isn’t a build-system. Or at least, that’s what I believe. And dune (or make) as a build system is perfectly capable of doing these things.

Which doesn’t mean you can’t do it with opam: just that, well, it’s a lot more cumbersome and slow.

1 Like
28

opam is useful to test the install of your packages and the effect of their ongoing development on other dependent packages.

For that one-shot opam install or sticky opam pin are tremendously useful as a development time-tool: to install interim versions of code, modify, then repeat. And this what a package manager is for, and opam is a package manager.

2 Likes