Yes, it would help to resolve the conflict with picomus, with 2 small changes in the undertaker source it would work (removing the install of picomus in the makefile and adding a "-q" to the call of picomus in BlockDefectAnalyzer.cpp) However, i don't want to link against the system-lib of picosat. 1. a measureable performance difference 2. accessability in distros without a picosat package
upgrading to picosat 960 is probably a good idea anyways because there are some bugs fixed from 959 (reported by me) and without the fixes, picomus isn't usable with stdin input mode. 2014-11-08 18:47 GMT+01:00 Michael Tautschnig <m...@debian.org>: > On Sat, Nov 08, 2014 at 16:37:18 +0100, Stefan Hengelein wrote: >> Hi, >> >> we have an in-tree variant of the PicoSAT because the newer, reentrant >> version of picosat is around 30% slower for our usage than the one >> we're currently using (936). >> However, the picomus export is done for compatibility reasons. The >> output format was changed several times and the version 954 and 959 >> have some problems with argument passing and reading from stdin. >> These problems are solved with 960 but 960 was just released a few weeks ago. >> So we could use either 936 or 960 and i thought hat was a elegant way >> to solve the problem. >> But i didn't think it might cause conflicts here. >> > [...] > > So would it help if I upgraded picosat to version 960? I suppose we might get > an > unblock as 1) picosat shouldn't disrupt any other packages and 2) we'd be > fixing > an RC bug. > > Please just let me know, I'm happy to upgrade. > > Best, > Michael > -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
