On Wed, Jun 18, 2014 at 07:57:28AM +0200, Pietro Abate wrote: > 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. stderr isn't blocked, so you should see debug messages already. (I was frequently spammed with "Ignore packages" lines, so I am pretty sure about this one). > 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 ... The reason is that the solver is now told which source package a binary package belongs to. At the moment this requires opening the Packages file & parsing the stanza. The way it is implemented at the moment is very inefficient as packages aren't sorted, so the parser is jumping back and forth and between files… that could be tuned. I wanted to look into promoting this information piece into the binary cache for different reasons already though, so I didn't want to delay Stefanos changes any further and fix this one way or another when it is decided. Best regards David Kalnischkies
Attachment:
signature.asc
Description: Digital signature