Johannes Berg <
joha...@sipsolutions.net> writes:
> On Mon, 2022-01-31 at 11:05 -0500, Greg Troxel wrote:
>>
>> so it looks like there are two problems:
>>
>> make test production assumes there is a ./bup at top level when the
>> build doesn't make it
>
> Looks like that's checked into the repo - are you not using git? Maybe
> it's missing from some tarball?
I am, but I was trying to clean, and it seemed really obvious that it
must be created by the build so I deleted it, and in running git status
I misssed it. After "git checkout bup":
$ gmake check
Refreshed lib/bup/checkout_info.py
Warning: pandoc not found; skipping manpage generation
./pylint
./pylint: doing nothing given ./configure --with-pylint=no
./bup features
/home/gdt/SOFTWARE/BUP/bup/bup: No module named bup.main
gmake: *** [GNUmakefile:213: test] Error 1
>> dev/bup-python expects to find ../lib, which if CWD is dev works, but
>> if CWD is top level does not
>
> what does
>
> script_home="$(cd "$(dirname "$0")" && pwd -P)"
>
> result in? Seems odd, because it wants to go from $0, maybe pwd -P is
> behaving differently?
I assume you mean in pytest. I added the obvious "echo $script-home"
right after assignment and then:
$ sh -x pytest
+ set -eu
+ dirname pytest
+ cd .
+ pwd -P
+ script_home=/home/gdt/SOFTWARE/BUP/bup
+ echo /home/gdt/SOFTWARE/BUP/bup
/home/gdt/SOFTWARE/BUP/bup
+ testlibdir=/home/gdt/SOFTWARE/BUP/bup/test/lib
+ export PYTHONPATH=/home/gdt/SOFTWARE/BUP/bup/test/lib
+ exec dev/bup-python -m pytest -v -m 'not release'
bup: unable find lib dir (No such file or directory): ./../lib
and tat looks ok
$ ls -l /home/gdt/SOFTWARE/BUP/bup/test/lib
total 2
-rw-r--r-- 1 gdt lexort 0 Dec 5 2020 __init__.py
drwxr-xr-x 2 gdt lexort 512 Jan 31 10:33 buptest
-rw-r--r-- 1 gdt lexort 738 Dec 5 2020 wvpytest.py
I think the problem is the bup command not finding
/home/gdt/SOFTWARE/BUP/bup/lib, which has the python code needed to run
commands.
On this system, pwd -P and pwd -L are the same and I don't think there
are symlinks.
Reading
I find
prepend_lib_to_pythonpath(const char * const exec_path,
and it seems to look for the "parent" and then look for lib within that.
I am wondering if the difference is that on my system, calling exec on
a symlink causes
char *parent = exe_parent_dir(exec_path);
to be the parent of the directory with the symlink, and on GNU/Linux, it
is the parent of the directory holding the file that the symlink points
to?
It seems to be the other way around (with the printf changed to print
variables):
$ dev/bup-python
bup: unable find lib dir (No such file or directory): parent=. bupmodpath=./../lib
Similarly perhaps the bup-as-symlink command fails to resolve path:
$ ./bup features
/home/gdt/SOFTWARE/BUP/bup/bup: No module named bup.main
$ PYTHONPATH=/home/gdt/SOFTWARE/BUP/bup/lib ./bup features
bup 0.32+
Source 37b8e2e3baf0b6b9900d7a60959d2da006ee3c61 2022-01-16 14:45:48 -0600
Python: 3.9.9
Command line editing (e.g. bup ftp): yes
Saving and restoring POSIX ACLs: no
Saving and restoring extended attributes (xattrs): no
So there's probably one problem.
It looks like exe_path, while ifdefed for NetBSD, is looking for
const int mib[] = {CTL_KERN, KERN_PROC, KERN_PROC_PATHNAME, -1};
and this is returning 0 as a result code but an empty string.
It appears this part of the sysctl mib has been withdrawn (and it's
certainly not specified by POSIX :-).
I commented out the NetBSD from the ifdef, resulting in the fallback
(searching in PATH) and tests are starting to run. However, I wonder if
I am testing with the bup lib that is installed (0.32) instead of git
master.
Overall this feels really fragile and non-portable, relying on things
not required by POSIX, and I wonder if it wouldn't be better to onfigure
in the path, and passing it in the env for tests. (I realize some
people think it's good to be able to move things around and drop them in
prefixes they weren't built for, but I view that as in general unsound
and not to be encouraged.)