Prereq: I use the following method to pull in the forge packages pkg load all I have tried both the g-octave method and the octave overlay version and I get the same type of problem. error: `is_real_vector' undefined near line 38 column 15 I have noticed the this .oct file is locate here: /usr/libexec/octave/packages/control-2.4.1/x86_64-pc-linux-gnu-api-v48+/is_real_vector.oct Which does not seem to be used by octave. A better and default path for octave is this path: /usr/lib64/octave/site/oct/x86_64-pc-linux-gnu/ My question, is it possible to place the forge .oct files in the path above instead of the current path. (Or links). Please note that I am new to ebuilds and octave-forge, so maybe this is completely stupid. Reproducible: Always Steps to Reproduce: 1. layman -a octave 2. emerge signal 3. octave 4. octave:1> pkg load all 5. octave:2> zp2tf ([1, 1], [0], 1) error: `is_real_vector' undefined near line 38 column 15 Working: 3. octave --path /usr/libexec/octave/packages/control-2.4.1/x86_64-pc-linux-gnu-api-v48+/ 4. octave:1> pkg load all 5. octave:2> zp2tf ([1, 1], [0], 1) ans = 1 -2 1
This path isn't hardcoded anywhere in g-octave. We use a makefile[1] provided by octave-forge, that gets all the paths from octave itself. [1] http://svn.code.sf.net/p/octave/code/trunk/octave-forge/packages/package_Makefile.in
(In reply to comment #1) > This path isn't hardcoded anywhere in g-octave. We use a makefile[1] > provided by octave-forge, that gets all the paths from octave itself. > > [1] > http://svn.code.sf.net/p/octave/code/trunk/octave-forge/packages/ > package_Makefile.in Would it be possible (if not too ugly) to have a script that links in the .oct files into a better path. This script could be in the src_install() for the individual forge packages. I wonder, do other people have this problem or it is just me?
Um, this hasn't been resolved at all, nor any pointers given to a solution. g-octave packages still install to a place where octave does not use it, and no documentation seems to even give a workaround. It would be easier to confirm that if g-octave.org actually resolved (judging by an earlier report on that issue, it seems to come and go?)... Having to scour bug reports just to find this is a known issue that was set to "resolved" without any actual resolution (or even a useful suggestion) is pretty annoying.
(In reply to comment #3) > Um, this hasn't been resolved at all, nor any pointers given to a solution. > g-octave packages still install to a place where octave does not use it, and > no documentation seems to even give a workaround. It would be easier to > confirm that if g-octave.org actually resolved (judging by an earlier report > on that issue, it seems to come and go?)... Having to scour bug reports just > to find this is a known issue that was set to "resolved" without any actual > resolution (or even a useful suggestion) is pretty annoying. yeah, it was resolved, and the resolution is: I can't fix it, please report this bug upstream. g-octave just uses files (configure and Makefile) provided by octave-forge upstream. These path *is* set by octave-forge upstream. You should ask them to fix it, not me.
In my opinion there are four things that could be done: 1) Tell users to use the --path switch when launching octave. Ugly but at-least a way around it. 2) Tell users to create symbolic links of all the critical .oct files to a file that octave actually uses by default. 3) In the ebuild create a post_install that creates the symbolic links as above. 4) Dig deep into the octave and g-forge ebuilds to find the configure switch/path/argument to align the packages. I am pretty sure it is possible to work this. I am not saying it is easy but probably possible. That said, I think that Rafael is correct in that we should report this upstream. This I think can be done as a first step and then attack some/all of the points above. My 2-cents.
> 4) Dig deep into the octave and g-forge ebuilds to find the configure > switch/path/argument to align the packages. I am pretty sure it is possible > to work this. I am not saying it is easy but probably possible. From http://octave.sourceforge.net/developers.html # package/Makefile This is an optional file that is for the use of Octave-Forge only. It allows the developer to have fine control over exactly what is included in the package and anything that needs to be done before or after the package is built. The default Makefile is include ../../Makeconf PKG_FILES = COPYING DESCRIPTION $(wildcard INDEX) $(wildcard PKG_ADD) \ $(wildcard PKG_DEL) $(wildcard post_install.m) \ $(wildcard pre_install.m) $(wildcard on_uninstall.m) \ $(wildcard inst/*) $(wildcard src/*) $(wildcard doc/*) \ $(wildcard bin/*) pre-pkg/%:: # Do nothing prior to packaging post-pkg/%:: # Do nothing post packaging which packages all of the required and existing optional files and directories discussed here.
g-octave is open source (GPL-2). pull requests are welcome, if they make sense, and aren't fixing bugs that belongs to upstream. If you think that this bug belongs to g-octave, create a patch, send me and I'll see if it really makes sense. https://github.com/rafaelmartins/g-octave
@Niklas: please try again with g-octave-0.4.1-r4 reinstalling the control package).
(In reply to Fabio Rossi from comment #8) > @Niklas: please try again with g-octave-0.4.1-r4 reinstalling the control > package). I reinstalled g-octave and signal (control). I now have the following: $ emerge g-octave -pv [ebuild R ~] g-octave/control-2.4.1::octave 0 kB [ebuild R ~] app-portage/g-octave-0.4.1-r4 USE="-doc {-test}" 0 kB [ebuild R ~] g-octave/signal-1.2.0::octave 0 kB I got the following error: octave:1> pkg load all octave:2> zp2tf ([1, 1], [0], 1) error: 'is_real_vector' undefined near line 38 column 15 error: called from: error: /usr/share/octave/packages/control-2.4.1/@tfpoly/tfpoly.m at line 35, column 7 error: /usr/share/octave/packages/control-2.4.1/__vec2tfpoly__.m at line 32, column 7 error: /usr/share/octave/packages/control-2.4.1/@tf/tf.m at line 213, column 5 error: /usr/share/octave/packages/control-2.4.1/zpk.m at line 101, column 11 error: evaluating argument list element number 1 error: /usr/share/octave/packages/signal-1.2.0/zp2tf.m at line 41, column 15 If I instead did this: octave --path /usr/libexec/octave/packages/control-2.4.1/x86_64-pc-linux-gnu-api-v48+/ octave:1> pkg load all octave:2> zp2tf ([1, 1], [0], 1) ans = 1 -2 1 octave:3> I will add an emerge --info file. Is there anything else I can provide help with don't hesitate to ask. And thank you very much for working on this issue!
Created attachment 361376 [details] emerge --info
(In reply to Niklas Johansson from comment #9) > I reinstalled g-octave and signal (control). I now have the following: > > $ emerge g-octave -pv > [ebuild R ~] g-octave/control-2.4.1::octave 0 kB > [ebuild R ~] app-portage/g-octave-0.4.1-r4 USE="-doc {-test}" 0 kB > [ebuild R ~] g-octave/signal-1.2.0::octave 0 kB If the re-emerge sequence is the one indicated above then this is wrong and for this reason you still have the problem (basically the control package has been reinstalled with the old g-octave). In fact you still have the *.oct files in /usr/libexec as indicated below: > octave --path > /usr/libexec/octave/packages/control-2.4.1/x86_64-pc-linux-gnu-api-v48+/ I have just emerged control package on my 64 bit system with the new g-octave version and $ equery f g-octave/control| grep \\\.oct /usr/lib64/octave/packages/control-2.4.1/x86_64-pc-linux-gnu-api-v48+/__control_slicot_functions__.oct /usr/lib64/octave/packages/control-2.4.1/x86_64-pc-linux-gnu-api-v48+/is_matrix.oct /usr/lib64/octave/packages/control-2.4.1/x86_64-pc-linux-gnu-api-v48+/is_real_matrix.oct /usr/lib64/octave/packages/control-2.4.1/x86_64-pc-linux-gnu-api-v48+/is_real_scalar.oct /usr/lib64/octave/packages/control-2.4.1/x86_64-pc-linux-gnu-api-v48+/is_real_square_matrix.oct /usr/lib64/octave/packages/control-2.4.1/x86_64-pc-linux-gnu-api-v48+/is_real_vector.oct and the /usr/lib64/octave/packages/control-2.4.1/x86_64-pc-linux-gnu-api-v48+ path is correctly added by the octave init script octaverc by the pkg("load", "auto") function call. You can also verify this from octave command line with the path function. Please unmerge and reemerge all packages *after* g-octave-0.4.1-r4 installation *** This bug has been marked as a duplicate of bug 488534 ***
> If the re-emerge sequence is the one indicated above then this is wrong and > for this reason you still have the problem (basically the control package > has been reinstalled with the old g-octave). In fact you still have the > *.oct files in /usr/libexec as indicated below: > Please unmerge and reemerge all packages *after* g-octave-0.4.1-r4 > installation I did not do it in this order. Nonetheless I redid it today. I removed g-octave and signal and control. And reinstalled them in this order: emerge g-octave emerge --config =g-octave-0.4.1-r4 emerge signal emerge control I still go the same error: octave:1> pkg load all octave:2> zp2tf ([1, 1], [0], 1) error: 'is_real_vector' undefined near line 38 column 15 error: called from: error: /usr/share/octave/packages/control-2.4.1/@tfpoly/tfpoly.m at line 35, column 7 error: /usr/share/octave/packages/control-2.4.1/__vec2tfpoly__.m at line 32, column 7 error: /usr/share/octave/packages/control-2.4.1/@tf/tf.m at line 213, column 5 error: /usr/share/octave/packages/control-2.4.1/zpk.m at line 101, column 11 error: evaluating argument list element number 1 error: /usr/share/octave/packages/signal-1.2.0/zp2tf.m at line 41, column 15
please post the results of $ equery f g-octave/control| grep \\\.oct and, inside octave, > path
Created attachment 361562 [details] equery f
Created attachment 361564 [details] path
Please verify that /usr/share/g-octave/g-octave.eclass contains sed -i -e 's@libexec@lib@g' "${S}/Makefile" || die 'sed failed.' inside g-octave_src_prepare(). If this is the case then # ebuild /var/lib/g-octave/g-octave/control/control-2.4.1.ebuild prepare should produce a file /var/tmp/portage/g-octave/control-2.4.1/work/control/Makefile that doesn't contain any reference to libexec.
