On 17/06/14 22:17, David Kalnischkies wrote: > > E: Sub-process aspcud returned an error code (1) > > This check is new in 1.0.4, previously the exit code was ignored (and > even segfaults…), but the documentation of the EDSP protocol > specifically says that the solver should always exit with 0 even if it > failed to find a solution, aka: Looks like you found a situation in > which the solver exits with a non-zero statuscode.
yup. Actually there are many cases in which apt-cudf exit with 1. If the solver fails to find a solution, it means that a solution does not exists at all, but the execution of the solver was successful. If apt-cudf exists with 1, it means that it wasn't able to run the solver at all (and I cannot say anything about the solution). Moreover, with exit code 1, I always print on stderr a debugging message. Maybe you can catch it and propagate it to he apt-get user. This will make it easier for us to debug other problems in the future. An empty EDSP might be well the cause of this specific problem. OT: I've also the impression that the interaction between apt-get and apt-cudf is now a bit slower. Just try to dump an edsp and than pass it directly to apt-cudf. you will notice that it is kinda fast to give you back and answer. I don't understand why it takes so long when apt-get calls apt-cudf directly (Are you flushing the stdout too often ?). Maybe I should open a new bug report for this one ... thanks ! pietro -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
