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 <post@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 >
Attachment:
signature.asc
Description: This is a digitally signed message part.