Package: wnpp
Severity: normal
X-Debbugs-CC: mdet...@cs.nyu.edu
Niels,
Thanks for the suggestion, but I can't effectively act on it. I've had
bug fixes waiting for sponsorship since March with no response. I
can't make any changes to the package until a Debian Developer steps
up who can actually upload it to unstable.
-Chris
On Tue, Jun 19, 2012 at 3:36 PM,
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
* Adding Replaces/Conflicts to libcvc3-5-jni for libcvc3-2-jni
(Closes: #662200)
* Leaving .el files in site-lisp directory when installing cvc3-el
(Closes: #665319)
-- Christopher L. Conway Wed, 11 Apr 2012 10:02:19 -0400
Regards,
Chris
--
To UNSUBSCRIBE, email to debian-bugs
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
Closes: #660244)
* Updating to standards version 3.9.2
* Switching to dpkg-source 3.0 (quilt) format
* Changing default-jdk-builddep build dependency to default-jdk
* Re-enabling libcvc3-jni on kfreebsd-amd64 (Closes: #576335)
-- Christopher L. Conway Sat, 25 Feb 2012 13:54:15 -
Regards,
Chris
On Sun, Feb 26, 2012 at 6:23 AM, wrote:
> How much?
>
I meant "sponsor" as in initiate an upload of the package to the unstable
repository. It's free, if you happen to be a Debian Developer (
http://wiki.debian.org/DebianMentorsFaq#Sponsored_Packages). :-)
I haven't been in touch with my previo
I've prepared a new package for v2.4.1. Let me know if you are able to
sponsor it.
-Chris
On Fri, Feb 17, 2012 at 11:31 AM, wrote:
> Package: cvc3
> Version: 2.2-13.1
> Severity: wishlist
>
> It would be nice if you could update to the latest upstream version (27
> January 2012 or later). The c
I agree with Andreas. This bug makes the package unusable and should
be prioritized.
The problem is that cedet.el tries to load all of the packages cogre,
ede, eieio, semantic, speedbar, cedet-contrib on startup and fails if
it can't find any of them. But cedet.el is installed by cedet-common,
whi
I'm working around this bug in the next version of the CVC3 package by
removing kfreebsd-amd64 from the supported architectures of
libcvc3-jni. If anybody could provide advice on a proper fix, it would
be greatly appreciated.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
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-dist-requ...@lists.debian.org
with a subject of
This version of the bug is for the JVM core dump on kfreebsd-amd64.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Package: ftp.debian.org
User: release.debian@packages.debian.org
Usertags: rm
--
To UNSUBSCRIBE, email to debian-bugs-dist-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
This package has been uploaded to mentors.debian.org and needs a sponsor:
http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=cvc3
It has also been uploaded to REVU:
http://revu.ubuntuwire.com/details.py?package=cvc3
Is there: (a) a standard way to peg my ocaml packages at 3.10.1 until
the transition is complete, or (b) anything I can do to help get
camlidl updated more quickly?
Regards,
Chris
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Package: camlidl
Severity: normal
*** Please type your report below this line ***
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.24-17-generic (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CT
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
26 matches
Mail list logo
