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