Thanks for the prompt fix.
Verified on my Win10 systems with Octave-8.0.0. Also works on Linux (but we knew that).

I suppose this bug can be closed ?

Since patch cf5f46b2e052, I have a few issues on Windows. "pkg list" just shows a package list with package names, without the path. Furthermore, loading packages doesn't work anymore.

I tracked it down to cset cf5f46b2e052, where in private function expand_rel_path.m, regexprep stumbles over the Windows backslash path separators. That is, if I debug it, I get:

>> pkg list
## stepping into subfunctions until expand_rel_path L.37 ...
debug> loc
loc = C:\Programs\Octave\Octave-8.0.0_20220714D\mingw64
debug> pkg_list{i}.dir
ans = __OH__/share/octave/packages/optim-1.6.2
debug> regexprep (pkg_list{i}.dir, "^__OH__", loc)
ans = C:ProgramsOctaveOctave-8.0.0_20220714Dmingw64/share/octave/packages/optim-1.6.2
debug>

That string "C:ProgramsOctaveOctave-8.0.0_20220714Dmingw64/share/octave/packages/optim-1.6.2" doesn't look right to me ...

(tested w. 7.1.91 from July 16 & a recent 8.0.0)

>  because the "symbolic" package doesn't install any .oct files. (Is that true?)

That is correct.  Its a "noarch" package in Fedora-speak.

Thanks.

I think we are getting closer.
`canonicalize_file_name` is called on these paths in `pkg/private/make_rel_paths.m`. If I understand Philip's comments in bug #51632 correctly, we can't just drop that call.

`canonicalize_file_name` returns `[]` for non-existent files/folders.

Afaict, compiled .oct files would be installed at the `arch_prefix`. It probably doesn't exist when that code is executed because the "symbolic" package doesn't install any .oct files. (Is that true?)

Maybe, we should create these directories during `pkg install` unconditionally, and not rely on the package to create them.

As a workaround, you could probably create the missing directory manually before installing the package in your CI. Something like this might do that:

docker exec oc install -d /usr/lib/octave/packages

I'll look into how to fix that in Octave core.

I'll need to think about that. But it might be that we should still use the change you proposed in comment #1 even if this underlying issue is fixed.

Thank you for the instructions.
But to be honest, I'm a bit at a loss when it comes to running those docker images.
I installed docker on Ubuntu 22.04 with `sudo apt-get install docker.io`.
After that, I tried to pull Octave with the first command from comment #9. That didn't work unless I ran it with `sudo`.

It also looks like I need to start docker with `sudo` with whatever command I tried after that. Without `sudo`, it would always fail with something along these lines:

$ docker run -it --rm gnuoctave/octave:7.1.0 octave-cli --eval "geteuid ()"
docker: Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post "http://%2Fvar%2Frun%2Fdocker.sock/v1.24/containers/create": dial unix /var/run/docker.sock: connect: permission denied.
See 'docker run --help'.

I tested the following:

$ sudo docker run -it --rm gnuoctave/octave:7.1.0 octave-cli --eval "geteuid ()"
Entered start.sh with args: octave-cli --eval geteuid ()
Executing the command: octave-cli --eval geteuid ()
ans = 1111
error: ignoring const execution_exception& while preparing to exit

But as you can see, that doesn't return `0` for me. So, I'll probably not be able to reproduce the original issue with this anyway...

I also suspect that the "docker Octave" didn't run as root in comment #9 either. So, the package would be installed at a different location. And the folders in those commands won't be created.

Is there a way how I could replicate the situation for the original issue? (I.e., a "docker Octave" that will report that it runs as root.)

Thanks.

IIUC, that should mean that the package `prefix` will be set to `/usr/share/octave/packages`, and the package `arch_prefix` will be set to `/usr/lib/octave/packages`.

Do those look like valid paths in the container?

After installing a package, what do the following commands return?

docker exec oc octave-cli --eval "canonicalize_file_name ('/usr/share/octave/packages')"
docker exec oc octave-cli --eval "canonicalize_file_name ('/usr/lib/octave/packages')"

I'd need to look into how to setup a "containerized" Octave and how to run that. (Haven't done that before.)
Could you please give a pointer to instructions (preferably step-by-step for dummies) how to do that?

Could you also please check what the following commands return inside a "containerized" Octave (7.1.0 or newer)?

geteuid ()
OCTAVE_HOME ()
user_data_dir ()
__octave_config_info__ ("libdir")

The current main branch of symbolic should do it.  I've seen this most often on our CI/CD runs and when messing around with containers, not sure I've seen it locally yet.

But I think @alexvong1995 has.

Here is the proposed patch:


(file #53381)

This bug was originally reported in https://github.com/cbm755/octsympy/issues/1142

When running "pkg test symbolic" in CI, tests outside of the symbolic package are being run.

After some debugging, it appears that the m-file https://hg.savannah.gnu.org/hgweb/octave/file/04120d65778a/scripts/pkg/private/expand_rel_paths.m is causing problem.

This part of the code

    if (strncmpi (pkg_list{i}.dir, "__OH__", 6))
      pkg_list{i}.dir = [ loc pkg_list{i}.dir(7:end) ];
      pkg_list{i}.archprefix = [ loc pkg_list{i}.archprefix(7:end) ];

assumes "__OH__" is a prefix of "pkg_list{i}.archprefix" without actually checking it.

In our case, "pkg_list{i}.archprefix" is the empty path, causing "loc" (which is "/usr") to be prepended to the empty path. The end result is that the tests of all m-file inside "/usr" are being run.