[Pkg-octave-devel] Dynare FTBFS / Octave+gnuplot bug

[Thomas Weber]

On Tue, Oct 20, 2009 at 09:28:49AM +0000, Sébastien Villemot wrote:
> Hi,
> 
> Le lundi 12 octobre 2009 à 20:04 +0200, Thomas Weber a écrit :
> > On Mon, Oct 12, 2009 at 12:06:33PM +0200, Sébastien Villemot wrote:
> > > The Dynare testsuite runs a similar sequence of Octave instances with
> > > graphics and M-files created on-the-fly, hence the problem reported on
> > > kfreebsd-i386 arch. I had created a poor-man workaround in quilt patch
> > > "testsuite-octave3.2-crash-workaround" of Dynare package, but this is
> > > not enough, at least on some buildds. Increasing the sleep delay would
> > > probably solve the problem, but this is definitely not a satisfactory
> > > solution.
> 
> I have reported the bug against Octave 3.2 in both Debian BTS and Octave
> bug list. For the moment I got no answer from Octave developers. The
> Dynare package is still blocked from entering testing, because of an
> FTBFS on kfreebsd-i386.
> 
> There are several possible solutions (not all are mutually exclusive):
> 
> 1) Wait more for a response from an Octave developer

Hmm, well, we get this for free. So let's see how far we come ourselves.

> 2) Ask for a rebuild on kfreebsd-i386. This may succeed, because of the
> random nature of the bug.

This is only a short-term solution. The release team tends to tear and
feather maintainers who keep such bugs in their packages :)

> 
> 3) Patch the Octave package in Debian. I can provide a simple patch
> which fixes bug #550823. Instead of only reexamining the content of
> directories of the load-path when their modification time changes, the
> idea is to reexamine them at every search in the load-path. Of course
> this can have an adverse effect on performance, particulary on
> directories with a lot of files; I am however unable to quantify the
> possible loss of performance.

The performance hit *is* big. This whole caching stuff was introduced
because searching Octave's directory took quite some time for each
command.

> 4) Upload a new Dynare version. Since I now have a better understanding
> of bug #550823, I have a new version of the workaround for that bug,
> which I hope can make the Dynare package build successfully on all
> archs.
> 
> What are your preferences ?

The problem with limited granularity of mtime is actually known, e.g. 
http://lkml.indiana.edu/hypermail/linux/kernel/0110.0/0484.html

I tend to think that this should be "fixed" in Octave's realm. I'm
unsure what kind of fix:
1) Every command that changes the disk and every command that calls
external stuff (system()) could mark the cache as dirty.

2) Every time when a file is not found, instead of giving up
immediately, the cache is refreshed and searched again once.

I tend to think that 2) would be easier.

Anyway, for now I'd say introduce a work-around in Dynare. I have a
feeling that this issue isn't easily fixed.

	Thomas