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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]