Hi all, To update on this issue, I believe there is a solution we can agree on, and would hopefully not be too difficult to put in place :
- In the ocaml-mccs source [1], you can toggle dynamic linking to a system installation of GLPK copying src/glpk/dune-shared over to src/glpk/dune - It may then be packaged independently with that change. ocaml-mccs itself is a fork that has much diverged from the original MCCS [2] project, so would that be OK ? - We will be releasing a 2.0.5 patch release shortly, and having this issue solved would be lovely. I'd be happy to help with any build issues in the process. [1] https://github.com/AltGr/ocaml-mccs [2] http://www.i3s.unice.fr/~cpjm/misc/mccs.html > - Louis Gesbert, 26/02/2019 16:15 - > Hi all, > > Thanks a lot for the packaging efforts. It's not much tested in the wild > anymore, as Anil pointed out, but aspcud is still part of our test-suite and > _should_ work. > > The error you are getting is internal to aspcud, though (it happens between > gringo and aspcud itself), so that might point us to a discrepancy of > versions between aspcud/gringo/clasp, which already happened in the past. I > was unable to reproduce yet using the stable packages (clasp 3.2.1-3, gringo > 5.1.0-4, aspcud 1:1.9.1-2+b1) and opam master (which shouldn't change much). > It would be worth ① checking the tool versions, ② extracting the Cudf file > sent to the solver (set OPAMCUDFFILE=/tmp/foo), ③ checking the aspcud debug > output (by running it directly on the generated file). > > I understand that getting ocaml-mccs into Debian might not be easy. The mccs > version included has been so widely changed from the original (which is > unmaintained) that I would argue it is acceptable to include it besides the > original, maybe with a different name (the current one would suggest a > binding); but we do also include a stripped version of GLPK in the source. > That on the other hand is unpatched, and there are linking options to rely on > an external version (either statically or dynamically). I am willing to give > a hand if anyone feels like attempting to package it. > > FWIW, we are also working on a Z3 backend, which doesn't require new or > specific bindings. For that one, Debian packaging while relying on > `libz3-ocaml-dev` would probably be easier than the source distribution. > > Best, > Louis > > > > - Anil Madhavapeddy, 25/02/2019 19:16 - > > On Sun, 9 Sep 2018 10:44:14 +0200 Ralf Jung <p...@ralfj.de> wrote: > > > Hi Mehdi, > > > > > > > On 2018-09-07 12:42, Ralf Jung wrote: > > > >> Package: opam > > > >> Version: 2.0.0-2 > > > >> Severity: normal > > > >> > > > >> Dear Maintainer, > > > >> > > > >> Quoting from https://opam.ocaml.org/doc/2.0/External_solvers.html: > > > >> > > > >>> As of 2.0.0, opam comes with a CUDF solver built-in by default, so > > > >>> unless you > > > >>> have specifically compiled without it, you shouldn't have to be > > > >>> worried about > > > >>> installing an external solver. > > > >> > > > >> So, aspcud should at best be a recommendation, not a dependency. > > > >> Likely, it > > > >> should just be a suggestions; the internal solver is used by default > > > >> even when > > > >> aspcud is installed. > > > >> > > > > > > > > If I am not mistaken, the built-in solver is not enabled in the Debian > > > > package > > > > because we are missing ocaml-mccs to make it work. So, for now, the > > > > dependency > > > > is still needed. > > > > > > Oh... that's a bummer, because using the new built-in solver is one of the > > > biggest reasons to update to opam 2 for me. :/ aspcud keeps computing > > > really > > > strange solutions in some cases I frequently run into. > > > > > > > Dear Debian opam maintainers, > > > > It's really great to see opam 2.0.3 in Debian testing now! I just wanted > > to highlight the importance of using the builtin mccs solver in order > > to get a working opam installation on Debian Buster however. > > > > Right now, the opam repository seems to fail badly when using the > > aspcud solver out of the box: > > > > """ > > $ docker run -it debian:testing > > # apt update > > # apt install -y opam > > # opam init -ya > > [WARNING] Running as root is not recommended > > [NOTE] Will configure from built-in defaults. > > Checking for available remotes: rsync and local, git, mercurial, darcs. > > Perfect! > > > > <><> Fetching repository information > > ><><><><><><><><><><><><><><><><><><><><><> > > [default] Initialised > > > > User configuration: > > ~/.profile is already up-to-date. > > [NOTE] Make sure that ~/.profile is well sourced in your ~/.bashrc. > > > > > > <><> Creating initial switch (ocaml-system>=4.02.3) > > <><><><><><><><><><><><><><> > > [ERROR] Solver failed: "/usr/bin/aspcud > > /tmp/opam-xxx-4710/solver-in-4710-548b09 > > /tmp/opam-xxx-4710/solver-out-4710-8b8a2d > > > > -count(removed),-sum(request,version-lag),-count(down),-sum(solution,version-lag),-count(changed)" > > exited with code 1 "ERROR: > > grounder returned with non-zero exit status" > > """ > > > > I've CCed Louis Gesbert in case he can shed any light on how to > > make aspcud work more reliably, but I strongly suspect that we've > > been testing the builtin mccs for so long that it's become the only > > solver in the opam 2.0.x branch capable of actually working with > > the current opam-repository. > > > > regards, > > Anil > > >
