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

[Dirk Eddelbuettel]

reassign 345241 octave-forge
thanks

On Fri, Dec 30, 2005 at 09:06:35PM +0100, Martin Samuelsson wrote:
> 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.

Indeed -- that is my old-style programming in debian/rules which the Debian
Octave Maintainers group hasn't replaced.  Once you remove that you should
be fine.

> 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)

[ Well, as the reaction time will vary from maintainer to maintainer, I do
not think you even have a point in generalising about it. I have never sat
on patches long and I have answered most of the wishlist bug quickly too .. ]

The straightforward matter would be to a) derive a patch to debian/rules, b)
to test that patch and then c) to send it to the maintainer. I tend to
prefer c) as private mail; others prefer the BTS.

> > 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.

Octave-forge transparently "overloads" some Octave commands by placing files
with identical names in earlier positions in the search path.  I would
suspect that all of this is mostly an issue of the C++ transition, ie mixing
Octave (from a new build) with octave-forge (from an old one). That is just
a hunch, it may well be something else.

One could start by invoking Octave with the --vanilla argument to make sure
no extra things get loaded at startup.

> 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.
> "

Sure. But we already know this is caused by octave-forge so ...

> 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.

It eeds to be reassigned to octave-forge, and this message should do just
that.

Dirk

-- 
Hell, there are no rules here - we're trying to accomplish something. 
                                                  -- Thomas A. Edison