Lucas,
A new version of this package has been languishing unsponsored on
mentors for two months: http://mentors.debian.net/package/cvc3. Can
you check that the problem persists in that version?
-Chris
On Tue, May 8, 2012 at 8:11 AM, Lucas Nussbaum wrote:
> Source: cvc3
> Version: 2.4.1-2
> Seve
I've uploaded a new package to mentors that addresses this and #662198. I
decided to add a Replaces/Breaks on libcvc3-2-jni, since the file
/usr/lib/jni/libcvc3jni.so appears to be necessary for the binary package
to function.
-Chris
On Mon, Mar 5, 2012 at 11:08 AM, Christopher L C
On Mon, Mar 5, 2012 at 3:08 AM, Ralf Treinen wrote:
> Hello,
>
> On Sun, Mar 04, 2012 at 01:22:19PM -0500, Christopher L Conway wrote:
> >Not sure how to handle this. On the C++ side, the policy dictates a
> >libcvc3-X package with libcvc3.so.X and a libcv
Not sure how to handle this. On the C++ side, the policy dictates a
libcvc3-X package with libcvc3.so.X and a libcvc3-X-dev package with
libcvc3.so -> libfoo.so.X. On the Java side, we don't have any headers to
install, so a libcvc3-X-jni-dev package seems like overkill just for a
libcvc3jni.so sym
I'm preparing a new version of the source package, changing the dev package
to libcvc3-dev with Conflicts/Replaces for libcvc3-5-dev and libcvc3-2-dev.
I suppose we should also delete libcvc3-5-dev from the repository. (In that
case should I remove the Conflicts/Replaces for that package?)
-Chris
This appears to be caused by the following assignment in
src/sat/minisat_solver.cpp, line 1582:
d_assigns[var] = toInt(lbool(p.sign()));
d_assigns has type vector. On the affected architectures, char
is unsigned. When p.sign() is -1, the result is that d_assigns[var] is
assigned 255, an unsig
Michael Tautschnig reports:
The problem, at least for most of the build failures, is a very simple one: An
endianness issue, which actually lies in the original MiniSat code. The
declaration of d_assigns in line 251 of src/sat/minisat_solver.h declares the
assignments as a vector of chars; assign
I've requested removal of the failing binaries here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=576333
The regression failures appear to fall into two classes. I've cloned a
bug for the std::bad_alloc error here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=576334
The JVM crash
This version of the bug is for tracking the failures on armel,
powerpc, and s390. (armel doesn't print the std::bad_alloc message,
but it fails in the same place. Let's assume this is the same bug for
now.)
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "u
This version of the bug is for the JVM core dump on kfreebsd-amd64.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Kibi,
Thanks for reporting this. I've already file a bug upstream for these
errors. As the problem architectures are not directly supported by
upstream and I don't have access to testing machines for these
architectures, I'm not sure what the correct resolution is. Should I
remove these architectu
Disregard the previous patch in preference to the attached.
diff -ruN -x cvs -x CVS -x '*~' -x config.log /home/chris/downloads/pycaml/Makefile.in pycaml/Makefile.in
--- /home/chris/downloads/pycaml/Makefile.in 2003-09-17 01:30:14.0 -0400
+++ pycaml/Makefile.in 2008-05-06 21:49:38.0
The attached patch against the original source tree should solve the problem.
Regards,
Chris
On Tue, May 6, 2008 at 10:43 PM, Christopher L Conway
<[EMAIL PROTECTED]> wrote:
> The problem is that the relevant lines are trying to create function
> pointers, but the identifiers name
The problem is that the relevant lines are trying to create function
pointers, but the identifiers named are really macros.
The following example gives a similar error:
macroptr.c:
int f(int x, int y, int z) { return 0; }
#define FOO(x) f(x,0,0)
int (*p)() = &f;
int (*q)() = &FOO;
$ gcc macropt
14 matches
Mail list logo
