Bug#345241: [Pkg-octave-devel] Bug#345241: octave2.1: octave panics on start

[Martin Samuelsson]

Dirk Eddelbuettel @ 2005-12-30 (Friday), 07:22 (-0600)
> | The compilation has finished, but it seems like the build process did
> | not honour DEB_BUILD_OPTIONS. (Debian Policy 10.1 [1])
> | 
> [zap]
> | 
> | Unless someone tells me how to easily produce a debugable debian
> | package, I'm not spending more time on this bug.
> 
> Make sure you disable dh_strip in debian/rules.

I could try that, but I doubt that it will make any difference. The
DEB_BUILD_OPTIONS variable is honoured by dh_strip. My experience tells
me that the binaries are often stripped at some additional point in the
build process when nostrip fails.

Having a quick look at it shows that install is called with the -s flag
to strip the binaries in src/Makefile.

This is possibly another bug. Since the Debian policy only suggests that
DEB_BUILD_OPTIONS should be obeyed, I'm not sure if I should file a
wishlist for this or not. (Fixing it right away would be ideal, but
experience tells me again those things are seldom done as quickly as one
would wish)

> I do not but I just wanted to make sure you knew that this is not a generic
> bug. My system (a few years old, many packages, current and up-to-date
> testing, dual athlon cpu) runs Octave just fine as shown below. So I would
> think we need to downgrade the severity of the bug report.

Like Juergen Rinas wrote it another message in this thread, it occurs in
combination with octave-forge. I didn't get that far in hunting it down,
but I can now confirm that purging octave-forge from my system makes
octave work again.

I agree that adding a dependency conflict like he suggests would be a
good thing to do, but I'm not sure it is enough to remove the problem.
As http://www.octave.org/bugs.html says:

"
If Octave gets a fatal signal, for any input whatever, that is a bug.
Reliable interpreters never crash.
"

How octave-forge interacts with octave is beyond my knowledge. If they
are scripts started at invocation, the same bug could be triggered by
someone elses scripts as well. If there is a binary interface where it
is impossible to protect oneself against insane linkage, there is not
much to do. Maybe one could hope for a better error message explaining
what file/function that refered to an illegal pointer, but that might be
tricky enough to implement...

Someone who knows the internals should know what to do to actually close
the bug. If it needs to be around for any longer, lowering the severity
to important or possibly even normal would probably be a good idea.
--
/Martin