Bug#345241: [Pkg-octave-devel] Bug#345241: octave2.1: octave panics on start
With a fresh compile of octave-2.1.72 (no patches) and octave-forge from CVS, my debian system doesn't panic. When I compile and run against the Debian octave 2.1.72-8 it panics on every oct-file in octave-forge. The particular problem at startup is that dispatch.oct is called by a number of the PKG_ADD functions. As far as I'm concerned, this is not an octave-forge problem, as it works fine when I build octave myself on both FC4 and Debian unstable. - Paul On Dec 30, 2005, at 11:24 AM, J.Rinas wrote: This seems to be a problem in connection with the octave-forge package: After uninstalling the current testing version octave-forgre=2005.06.13-2 octave-2.1 started correctly on my system. Therefore I've installed the unstable version octave-forge=2005.06.13-4 . And It worked for me without the anoying panic. Therefore, it might be a good idea to add a conflict octave-forge = 2005.06.13-4 to the octave2.1 packages -- /Juergen ___ Pkg-octave-devel mailing list [EMAIL PROTECTED] http://lists.alioth.debian.org/mailman/listinfo/pkg-octave-devel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345241: [Pkg-octave-devel] Bug#345241: octave2.1: octave panics on start
On 7 January 2006 at 16:08, Paul Kienzle wrote: | With a fresh compile of octave-2.1.72 (no patches) and | octave-forge from CVS, my debian system doesn't panic. | | When I compile and run against the Debian octave 2.1.72-8 | it panics on every oct-file in octave-forge. The particular | problem at startup is that dispatch.oct is called by a | number of the PKG_ADD functions. Not here: [EMAIL PROTECTED]:~ dpkg -l octave-forge octave2.1 Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- ii octave-forge 2005.06.13-8 Contributed functions for GNU Octave from ht ii octave2.1 2.1.72-8 GNU Octave language for numerical computatio [EMAIL PROTECTED]:~ octave -q octave:1 rand(4) ans = 0.4886378 0.3294047 0.0239247 0.6818765 0.1531520 0.7299680 0.5646705 0.6134827 0.7655607 0.8345606 0.0041081 0.7246739 0.6205669 0.8305970 0.307 0.0303730 octave:2 help rand rand is the dynamically-linked function from the file /usr/lib/octave/site/oct/api-v13/i486-pc-linux-gnu/octave-forge/rand.oct -- Loadable Function: rand (X) [...] Debian testing, current, with a handful of unstable package to facilitate installation of some KDE packages. -- 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]
Bug#345241: [Pkg-octave-devel] Bug#345241: octave2.1: octave panics on start
On 30 December 2005 at 12:54, Martin Samuelsson wrote: | Martin Samuelsson @ 2005-12-30 (Friday), 09:23 (+0100) | I just started rebuilding octave again with DEB_BUILD_OPTIONS set to | nostrip noopt. Hopefully that will give some clues. | | The compilation has finished, but it seems like the build process did | not honour DEB_BUILD_OPTIONS. (Debian Policy 10.1 [1]) | | 12:43|lusa% file /usr/bin/octave-2.1.72 | /usr/bin/octave-2.1.72: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), stripped | | 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. | Does anyone know if there is a tool available to simply find out which | of the packages that octave2.1 depends on that have been updated in | Debian between 2.1.72-5 and 2.1.72-6? 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. Dirk [EMAIL PROTECTED]:~ octave-2.1.72 GNU Octave, version 2.1.72 (i486-pc-linux-gnu). Copyright (C) 2005 John W. Eaton. This is free software; see the source code for copying conditions. There is ABSOLUTELY NO WARRANTY; not even for MERCHANTIBILITY or FITNESS FOR A PARTICULAR PURPOSE. For details, type `warranty'. Additional information about Octave is available at http://www.octave.org. Please contribute if you find this software useful. For more information, visit http://www.octave.org/help-wanted.html Report bugs to [EMAIL PROTECTED] (but first, please read http://www.octave.org/bugs.html to learn how to write a helpful report). octave-2.1.72:1 a=1:3 a = 1 2 3 octave-2.1.72:2 quit [EMAIL PROTECTED]:~ ldd /usr/bin/octave-2.1.72 linux-gate.so.1 = (0xe000) liboctinterp.so = /usr/lib/octave-2.1.72/liboctinterp.so (0xb78e9000) liboctave.so = /usr/lib/octave-2.1.72/liboctave.so (0xb72f1000) libcruft.so = /usr/lib/octave-2.1.72/libcruft.so (0xb72a4000) liblapack.so.3 = /usr/lib/atlas/3dnow/liblapack.so.3 (0xb6c45000) libblas.so.3 = /usr/lib/atlas/3dnow/libblas.so.3 (0xb6717000) libfftw3.so.3 = /usr/lib/libfftw3.so.3 (0xb664) libreadline.so.5 = /lib/libreadline.so.5 (0xb660f000) libncurses.so.5 = /lib/libncurses.so.5 (0xb65cc000) libdl.so.2 = /lib/tls/libdl.so.2 (0xb65c8000) libhdf5-1.6.4.so.0 = /usr/lib/libhdf5-1.6.4.so.0 (0xb64c4000) libz.so.1 = /usr/lib/libz.so.1 (0xb64b) libgfortran.so.0 = /usr/lib/libgfortran.so.0 (0xb6455000) libm.so.6 = /lib/tls/libm.so.6 (0xb642f000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0xb6424000) libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0xb6348000) libc.so.6 = /lib/tls/libc.so.6 (0xb6211000) libg2c.so.0 = /usr/lib/libg2c.so.0 (0xb61e9000) libpthread.so.0 = /lib/tls/libpthread.so.0 (0xb61d6000) /lib/ld-linux.so.2 (0xb7feb000) [EMAIL PROTECTED]:~ dpkg -l octave2.1 Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- ii octave2.1 2.1.72-6 GNU Octave language for numerical computatio -- 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]
Bug#345241: [Pkg-octave-devel] Bug#345241: octave2.1: octave panics on start
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]
Bug#345241: [Pkg-octave-devel] Bug#345241: octave2.1: octave panics on start
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]
Bug#345241: [Pkg-octave-devel] Bug#345241: octave2.1: octave panics on start
package octave-forge severity 345241 normal tags 345241 etch thanks * Dirk Eddelbuettel [EMAIL PROTECTED] [2005-12-30 14:23]: reassign 345241 octave-forge thanks [...] It needs to be reassigned to octave-forge, and this message should do just that. Also, since there is no problem with the octave2.1 and octave-forge currently in sid, I the severity level must be lowered to normal and the bug must be tagged etch, and this message should do just that. As soon as the newest version of octave-forge will enter testing, I will close this bug report. -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
