Runme.sh can't access https://svn.code.sf.net/p/pyfltk/code/branches/fltk1.4
SteffenDuenner opened this issue · 9 comments
Me again (the guy with the failed Linux builds). Currently Linux builds are failing again with:
FAILED: pyFLTK-prefix/src/pyFLTK-stamp/pyFLTK-download /home/steffen/mrv2/BUILD-Linux-amd64/Release/pyFLTK-prefix/src/pyFLTK-stamp/pyFLTK-download
cd /home/steffen/mrv2/BUILD-Linux-amd64/Release/pyFLTK-prefix/src && /home/steffen/.local/lib/python3.10/site-packages/cmake/data/bin/cmake -E env LD_LIBRARY_PATH=/home/steffen/mrv2/BUILD-Linux-amd64/Release/install/lib64:/home/steffen/mrv2/BUILD-Linux-amd64/Release/install/lib: -- svn checkout -r 627 https://svn.code.sf.net/p/pyfltk/code/branches/fltk1.4 pyFLTK && /home/steffen/.local/lib/python3.10/site-packages/cmake/data/bin/cmake -E touch /home/steffen/mrv2/BUILD-Linux-amd64/Release/pyFLTK-prefix/src/pyFLTK-stamp/pyFLTK-download
svn: E170013: Unable to connect to a repository at URL 'https://svn.code.sf.net/p/pyfltk/code/branches/fltk1.4'
svn: E230001: Server SSL certificate verification failed: issuer is not trusted
because of a failed SSL certificate verification.
I already did a svn list https://svn.code.sf.net/p/pyfltk/code/branches/fltk1.4 (following this: https://www.techfinitive.com/explainers/how-do-i-fix-server-ssl-certificate-verification-failed-issuer-is-not-trusted-when-using-svn/) from a terminal and it's working without problems.
Ok. It seems your environment is very screwed up.
From the line you sent me, you seem to have a cmake in your local python directory (!?). Fix that first. Install it into /usr/local/bin or ~/bin if it is in your path.
Also, open a clean terminal and do:
echo $LD_LIBRARY_PATH
You seem to have the BUILD-Linux-amd64 directories already on your LD_LIBRARY_PATH, which you shouldn't add manually (the build script will take care of that for you and the environment.sh inside the installed directory of mrv2 too). This is likely the reason why the build is failing.
Go to another dir and check these two commands on a clean terminal:
cd ~
mkdir normal_checkout
cd normal_checkout
svn checkout -r 627 https://svn.code.sf.net/p/pyfltk/code/branches/fltk1.4 pyFLTK-normal
This one should create pyFLTK-normal
cd ~
mkdir cmake_checkout
cd cmake_checkout
/home/steffen/.local/lib/python3.10/site-packages/cmake/data/bin/cmake -E env LD_LIBRARY_PATH=/home/steffen/mrv2/BUILD-Linux-amd64/Release/install/lib64:/home/steffen/mrv2/BUILD-Linux-amd64/Release/install/lib: -- svn checkout -r 627 https://svn.code.sf.net/p/pyfltk/code/branches/fltk1.4 pyFLTK-cmake
The second one may likely fail due to your environment, but if it works, it should create pyFTLK-cmake.
Oh damn! I had this "cmake in local python" problem a few weeks ago. It was caused by an installation of stable-diffusion-webui :(
I already fixed it but now it has come back from the dead it seems.
- OK, first I did a "pip uninstall cmake" which got rid of that stupid additional cmake. Now my cmake is
> cmake --version
cmake version 3.27.9
CMake suite maintained and supported by Kitware (kitware.com/cmake).
> which cmake
/usr/local/bin/cmake
-
echo $LD_LIBRARY_PATH
is empty. -
the first SVN checkout command works fine
-
the second one fails because I removed this cmake a few minutes ago ;)
I updated stable-diffusion-webui a few days ago and I wonder what went wrong there in the first place, because it keeps adding cmake to my local python dir when it should use Python in a venv.
I will try building again later, have to leave right now.
Sorry for the noise...
OK, I'm back and I'm getting somewhere. I did this (replaced the former cmake in local Python path with my system's cmake):
cmake -E env LD_LIBRARY_PATH=/home/steffen/mrv2/BUILD-Linux-amd64/Release/install/lib64:/home/steffen/mrv2/BUILD-Linux-amd64/Release/install/lib: -- svn checkout -r 627 https://svn.code.sf.net/p/pyfltk/code/branches/fltk1.4 pyFLTK-cmake
This gave me:
Error validating server certificate for 'https://svn.code.sf.net:443':
- The certificate is not issued by a trusted authority. Use the
fingerprint to validate the certificate manually!
Certificate information:
- Hostname: code.sourceforge.net
- Valid: from Jan 5 03:12:16 2024 GMT until Apr 4 03:12:15 2024 GMT
- Issuer: R3, Let's Encrypt, US
- Fingerprint: 0F:A0:0B:87:18:F5:66:AE:35:2C:11:3F:27:57:A7:45:7B:6C:A5:9B
(R)eject, accept (t)emporarily or accept (p)ermanently?
where I could permanently accept the certificate. After that I could successfully build mrv2 with "./runme.sh".
I'm glad you got it working. Still...
There's likely something still broken. LD_LIBRARY_PATH should have been empty in the "cmake -E env ..." line if you started ./runme.sh with an empty LD_LIBRARY_PATH.
The value at start-up is stored in etc/build_dir.sh and then used in cmake/Modules/BuildpyFLTK.cmake.
Can you add in runme_nolog.sh:
echo "USD support ........................ ${TLRENDER_USD} (TLRENDER_USD)"
# Add these two lines here
echo "LD_LIBRARY_PATH=$LD_LIBRARY_PATH"
echo "OLD_LD_LIBRARY_PATH=$OLD_LD_LIBRARY_PATH"
And then run ./runme.sh without starting the build and see what it prints for those two variables.
Here I am again. I added the two lines and it gives me
LD_LIBRARY_PATH=/home/steffen/mrv2/BUILD-Linux-amd64/Release/install/lib64:/home/steffen/mrv2/BUILD-Linux-amd64/Release/install/lib:/home/steffen/mrv2/BUILD-Linux-amd64/Release/install/lib64:/home/steffen/mrv2/BUILD-Linux-amd64/Release/install/lib:
OLD_LD_LIBRARY_PATH=/home/steffen/mrv2/BUILD-Linux-amd64/Release/install/lib64:/home/steffen/mrv2/BUILD-Linux-amd64/Release/install/lib:
A simple echo $LD_LIBRARY_PATH is empty though.
Thanks. What I suspected. Your OLD_LD_LIBRARY_PATH is set to something which it should not be. That's what's causing you a headache with pyFLTK.
What about a simple echo $OLD_LD_LIBRARY_PATH on a new terminal. Is it also empty? It should be. If it isn't, you need to figure out where do you set it. It should only be set in etc/build_dir.sh if it is not set already.
OK, echo $OLD_LD_LIBRARY_PATH is also empty.
I see what was going on. It was an ugly build bug on my part which I missed due to my environment. It is now fixed. Feel free to do a git pull and rebuild again (if you want to get my latest FFmpeg improvements on the saving of codecs which are really cool now).
Awesome! Thanks a lot.