Earthdata Forum

I've been trying to install SeaDAS 7.4 and OCSSW packages on a 64-bit Ubuntu machine here, and have run into a problem. I'm getting error
"/home/vimal/seadas/ocssw/run/scripts/ocssw_runner: line 21: pyverchk.py: command not found
Error - Python version is not new enough to install luts".

and my python version is  Python 2.7.12.

It would be better to start a new topic such as "SeaDAS 7.4 OCSSW install on linux -- pyverchk.py not found" so the answer is easier to find for the next person who encounters the problem.

It could be useful to know the Ubuntu version.   What do you get when you run the following command in a terminal:
ls -l /home/vimal/seadas/ocssw/run/scripts/pyverchk.py?  Is your python the verson supplied by the distribution or
did you install it separately (e.g., using the Anaconda distribution)?

I've installed SeaDAS 7.4 on many linux systems and not seen this error, so it is possible that your system has some other problem such as a full disk or permission conflicts.

(Note from the admin - post moved as suggested :grin:)

Thank you very much!

Through distribution i installed Python not by separately. while running the command "ls -l /home/vimal/seadas/ocssw/run/scripts/pyverchk.py"
I'm getting
"-rwxrwxr-x 1 vimal vimal 2300 Mar 13 09:29 /home/vimal/seadas/ocssw/run/scripts/pyverchk.py".
And how to find the full disk or permission conflicts? what i have to do for resolving these conflicts?
And my friends/colleagues who already installed seadas in Linux system getting the same error while "update OC processor".

I can confirm this error on Ubuntu 16.04.  The GUI updater appears to have installed a future version of the OCSSW_bash.env file.  This version sets the PATH variable to directories that don't match the locations in version 7.4.  The install_ocssw.py script replaces the existing file with OCSSW_bash.env   To see if this is your problem, run ls -l ~/seadas/ocssw/OCSSW_bash.env.  For version 7.4 this should be 2894 bytes, but the current installer gives a version with 3001 bytes.

George, you are correct.  A new OCSSW_bash.env got pushed to the web server accidentally.

Try updating OCSSW.  It should work now.

don

Yes you are correct!
while run "ls -l ~/seadas/ocssw/OCSSW_bash.env",
I got "-rw-rw-r-- 1 vimal vimal 3001 Nov 14 02:06 /home/vimal/seadas/ocssw/OCSSW_bash.env".
After update its working fine now "-rw-rw-r-- 1 vimal vimal 2894 Mar 14 22:36 /home/vimal/seadas/ocssw/OCSSW_bash.env".


Thank you very much!

I'm facing another problem while BuildIt. i'm getting error

checking for string.h... (cached) yes
checking stdio.h usability... yes
checking stdio.h presence... yes
checking for stdio.h... yes
checking for stdlib.h... (cached) yes
checking locale.h usability... yes
checking locale.h presence... yes
checking for locale.h... yes
checking for debug enabled... no
checking for exp in -lm... yes
checking zlib.h usability... yes
checking zlib.h presence... yes
checking for zlib.h... yes
checking for library containing inflateInit_... -lz
using zlib from /usr/include
checking for library containing jinit_compress_master... -ljpeg
using jpeg from /home/vimal/seadas/ocssw/build/lib3/include
checking for TIFFOpen in -ltiff... no
configure: error: failed to link with -ltiff to find TIFFOpen
***** configure failed *****
***** BuildIt (geotiff) failed *****

    But i already installed all the necessary libraries like geotiff and tiff libraries.

Once again -- start a new topic for a new problem so thers can find it more easily

Building the OCSSW software is a big job, so unless your IT policies don't let you use binaries from NASA or you need to modify the programs, it saves a lot of time use the NASA supplied versions.  On linux it is not enough to install libraries, you also have to install the developer packages for each library needed in the build.  This can be tedious, but there are some tools (see Debian Building Tutorial) to help.  This tutorial is for people building distro packages.  Although the OCSSW programs aren't in Debian/Ubuntu packages, many of the 3rd party libraries have distro packages.  It can be tedious if you run BuildIt over and over for every missing library, so it is faster to get devleoper packages before running BuildIt.   Also note that once a library has been build you can edit BuildIt to remove it from the list so you don't build the same library over and over.  If you obtain the developer packages distro versions of the 3rd-party libraries (OCSSW provides these because distros often provide outdated versions or build them with different options) you will get most of developer packages you need.   There are a few programs that are often used along with the OCSSW software, such as gdal and nco, so I generally get the developer packages needed to build gdal and nco before attempting to build the 3rd party libraries.  This approach greatly reduces the number of failures with BuildIt.   Developer packages are generally small, so it doesn't hurt to have a few that won't actually be used.

Thank you very much ! gnwiii and dshea.
I removed all the libraries which i installed manually and after that using developer package it get installed while BuildIt.