octave-stk @2.2.0_0: update to 2.2.1

[Schamschula (Marius Schamschula)]

octave-stk has been updated to version 2.2.1:

* Octave 4.0 compliance

   o Fix unit tests

* Octave package

   o Do not ship stk_test and stk_runtests with the Octave package

[michaelld (Michael Dickens)]

octave-stk does not do a standard install, just FYI. The top-level DESCRIPTION file isn't the usual format, for example. Also when I try to load the module in octave, I get:

octave:1> pkg load stk
warning: addpath: /opt/local/lib/octave/packages/stk-2.2.1/x86_64-apple-darwin12.6.0-api-v49+/config: No such file or directory
error: 'stk_config_mole' undefined near line 42 column 1
error: called from:
error:   /opt/local/lib/octave/packages/stk-2.2.1/x86_64-apple-darwin12.6.0-api-v49+/PKG_ADD at line 42, column 1
error:   /opt/local/share/octave/3.8.2/m/pkg/private/load_packages_and_dependencies.m at line 47, column 5
error:   /opt/local/share/octave/3.8.2/m/pkg/private/load_packages.m at line 60, column 3
error:   /opt/local/share/octave/3.8.2/m/pkg/pkg.m at line 412, column 7

So ... not sure if the issues are just for this version, or in general.

[Schamschula (Marius Schamschula)]

I just reverted to octave-stk @2.2.0_0. No such problem here.

I'll have to investigate this one a bit further.

[michaelld (Michael Dickens)]

OK; good. Ping this ticket when you're ready & I'll test, verify, and commit.

[Schamschula (Marius Schamschula)]

Replying to michaelld@…:

OK; good. Ping this ticket when you're ready & I'll test, verify, and commit.

Michael,

This appears to be a MacPorts issue. After posting a ticket on the octave forge tracker ​https://savannah.gnu.org/bugs/index.php?45091, and getting some feedback from there, I tried installing the stk 2.3.0-RC2, but ran into the same issue.

So I went back and tried installing stk 2.2.1 from within octave: success, no error while loading. So the issue appears to be somewhere in octave-1.0.tcl.

[michaelld (Michael Dickens)]

Interesting. I did some sleuthing just now & confirm your finding / belief. What seems to be happening is that the "post-deactivate" and "post-activate" hooks in the octave-1.0 PortGroup are not quite working -- they leave behind cruft (or, rather, something is leaving behind cruft in /opt/local/lib/octave/packages and /opt/local/share/octave/packages, maybe elsewhere). And, that cruft is, for some reason, being found ahead of the actual pkg contents. So, for example, if you never had octave-stk installed then -any- version should work; if anything prior to 2.2.0 was installed, then there is cruft hanging around which tries to do the load & fails because the octave load paths are not correct. When I remove this cruft, all is well again. I'm just not sure why there is cruft yet. I'll look into those hooks & see what I can figure out. Cruft happens :)

[michaelld (Michael Dickens)]

Removing the cruft allows 2.3.0 to work, too, but I can't push this fix until the octave PortGroup works.

[Schamschula (Marius Schamschula)]

Replying to michaelld@…:

Interesting. I did some sleuthing just now & confirm your finding / belief. What seems to be happening is that the "post-deactivate" and "post-activate" hooks in the octave-1.0 PortGroup are not quite working -- they leave behind cruft (or, rather, something is leaving behind cruft in /opt/local/lib/octave/packages and /opt/local/share/octave/packages, maybe elsewhere). And, that cruft is, for some reason, being found ahead of the actual pkg contents. So, for example, if you never had octave-stk installed then -any- version should work; if anything prior to 2.2.0 was installed, then there is cruft hanging around which tries to do the load & fails because the octave load paths are not correct. When I remove this cruft, all is well again. I'm just not sure why there is cruft yet. I'll look into those hooks & see what I can figure out. Cruft happens :)

Apropos cruft: After uninstalling octave-stk a couple of directories remain in the path sea. I had to manually remove them using rmpath.

[michaelld (Michael Dickens)]

Yeah; it looks like the issue is with 2.2.0 and prior, which (for some reason) install into $prefix/lib/octave/packages, while 2.3.0 installs into $prefix/share/octave/packages. So, I'm trying adding to the deactivate hook a loop which looks in both of these directories and removes any installed version of the specific package (only; no other packages). In this way, the cruft should be removed no matter which version is being used. Not sure it works as expected yet though ... I'm still also trying to understand that various phases of octave's pkg command; maybe there's a better way to do this?

[Schamschula (Marius Schamschula)]

Michael,

That makes at least two of us…

octave-1.0.tcl definitely is one of the more nebulous/obscure routines within MacPorts.

[michaelld (Michael Dickens)]

Ok; so here's the actual problems:

In octave-1.0 PortGroup, we set "pkg prefix ${prefix}/share/octave/packages ${prefix}/lib/octave/packages", which (according to "octave> help pkg") puts non-arch files into the former directory and arch-specific files into the latter directory. For most packages, this separation is not an issue -- or, more likely, there is no real separation so it's a non-issue. But, for this new STK it is an issue & you can verify that the binaries do end up in lib while the m-scripts end up in share. STK works only when all of these files are in the same directory structure -- PKG_ADD and PKG_DEL make this clear -- but it probably won't be difficult to work around this if we really wanted to. So, STK is at fault here, assuming that all of its files will be installed into the same directory structure while octave offers alternatives. That said, there's more to this issue, too.

The cruft part happens because octave does not always perform cleanup properly when the prefix is defined as above -- sometimes it does and sometimes it does not (not clear to me when/why). So, removing cruft is important, but not sufficient to get STK working.

I think the best solution is to just install all pkg files into either lib or share, and not separate the arch and non-arch files out -- no matter how attractive this might be. Doing this solves 2 problems: 1) packages like STK will work; 2) octave should properly clean up packages when uninstalling/deactivating them (but, we can leave the cruft remover for legacy use of this PortGroup). Doing this is a simple change to the octave-1.0 PortGroup, and since all of the other packages work then we don't need to rev-bump them; they will get moved as they get updated.

What fun!

[julien.bect@…]

Cc Me!

[julien.bect@…]

Replying to michaelld@…:

In octave-1.0 PortGroup, we set "pkg prefix ${prefix}/share/octave/packages ${prefix}/lib/octave/packages", which (according to "octave> help pkg") puts non-arch files into the former directory and arch-specific files into the latter directory. For most packages, this separation is not an issue -- or, more likely, there is no real separation so it's a non-issue. But, for this new STK it is an issue & you can verify that the binaries do end up in lib while the m-scripts end up in share. STK works only when all of these files are in the same directory structure -- PKG_ADD and PKG_DEL make this clear -- but it probably won't be difficult to work around this if we really wanted to. So, STK is at fault here, assuming that all of its files will be installed into the same directory structure while octave offers alternatives.

Hello Michael, hello Marius,

Actually, stk is supposed to behave like a standard octave package... Please report any non-standard behaviour as a bug on Octave Forge bug tracker:

​https://savannah.gnu.org/bugs/?func=additem&group=octave

Concerning the DESCRIPTION file which is mentioned above: if you can please you tell me in which way it is non-standard, I will fix it right away.

Concerning the directory structure: stk supports, like any other octave forge package, the separation of its files between an arch-independent and an arch-dependent directory.

I believe that (part of ?) the problems that you have in creating a binary package for MacPorts come in fact from a deeper bug in the octave function 'pkg' which is reported here:

​https://savannah.gnu.org/bugs/index.php?45369

See

​https://savannah.gnu.org/bugs/?45091

for more information.

@++ Julien (stk maintainer)

[Schamschula (Marius Schamschula)]

See #48143 regarding a patch for octave-1.0.tcl, a.k.a. the octave port group, to delete these files.

[michaelld (Michael Dickens)]

closing this ticket in favor of #48137; duplicate, sort of.