Bug#595921: Future unblock: frama-c/20100401+boron+dfsg-5

2010-10-05 Thread Mehdi Dogguy
On 07/09/2010 20:06, Adam D. Barratt wrote:
 On Tue, 2010-09-07 at 11:54 +0200, Mehdi Dogguy wrote:
 I received a tiny patch from upstream which fixes a performance bug
 that could lead to a stack overflow error (a crash) during large
 analyses.
 [...]
 Would it be ok for upload an updated Frama-C package with this change
 only?  Uploading a new Frama-C would require rebuilding Why as well on
 all architectures because it provides a plugin for Frama-C which
 contains a hash of some internal modules of Frama-C (that's needed by
 OCaml).
 
 Please go ahead, and let us know once the package has been accepted.
 

Uploaded.

Regards,

-- 
Mehdi Dogguy مهدي الدڤي
me...@{dogguy.org,debian.org}



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#595921: Future unblock: frama-c/20100401+boron+dfsg-5

2010-09-07 Thread Mehdi Dogguy
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: freeze-exception

Hi release team,

I received a tiny patch from upstream which fixes a performance bug
that could lead to a stack overflow error (a crash) during large
analyses. The patch is as follows:

Index: src/value/kf_state.ml
===
--- src/value/kf_state.ml   (revision 9760)
+++ src/value/kf_state.ml   (revision 9761)
@@ -44,7 +44,8 @@
try Value.is_accessible (Kstmt (Kernel_function.find_first_stmt kf))
with Kernel_function.No_Statement - false)

-let mark_as_called kf = Is_Called.add kf true
+let mark_as_called kf = Is_Called.replace kf true

 (* * *)
 (** {2 Callers} *)

There is no bug report for this issue (yet) since I got the patch
directly from upstream.

Would it be ok for upload an updated Frama-C package with this change
only?  Uploading a new Frama-C would require rebuilding Why as well on
all architectures because it provides a plugin for Frama-C which
contains a hash of some internal modules of Frama-C (that's needed by
OCaml).

And yes, the runtime dependencies of Why are somehow broken since it
doesn't reflect the need of at least the version of Frama-c which was
used during the build. I intended to work on that but didn't find
time. It will be fixed for Wheezy.

Regards,

-- 
Mehdi Dogguy

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-proposed-updates'), (500, 
'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#595921: Future unblock: frama-c/20100401+boron+dfsg-5

2010-09-07 Thread Adam D. Barratt
On Tue, 2010-09-07 at 11:54 +0200, Mehdi Dogguy wrote:
 I received a tiny patch from upstream which fixes a performance bug
 that could lead to a stack overflow error (a crash) during large
 analyses.
[...]
 Would it be ok for upload an updated Frama-C package with this change
 only?  Uploading a new Frama-C would require rebuilding Why as well on
 all architectures because it provides a plugin for Frama-C which
 contains a hash of some internal modules of Frama-C (that's needed by
 OCaml).

Please go ahead, and let us know once the package has been accepted.

Regards,

Adam



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org