As a new user, I am facing a situation where I’ve been pointed to centrally managed versions of the DM stack where I don’t have write access (e.g., weeklies at Lyon or installs at SLAC). I’ve been facing the situation where there are packages that I need that are not installed centrally (the most important example being lsst_sims). If I were pointing at my own version of the stack I would solve this problem with a eups distrib install; however, on centrally managed stacks I generally do not have write access. I’ve faced a similar problem before in other non-lsst environments, I’ve been able to cobble together a solution by installing my own version eups, prepending its path to my $EUPS_PATH, and using the --nolocks --no-server-tags options for eups distrib install.
So far, I haven’t been able to get a similar solution working with the DM stack. I was wondering if anyone else had solved the problem of installing on top of write-protected central installs.
My first attempt failed. I’m sticking with w_2017_26 using newinstall’s provided miniconda3, as I believe that nfs fix (https://jira.lsstcorp.org/browse/DM-11771) isn’t available in a weekly yet (is it?). The only change is the move to eups 2.1.4, which I introduced by changing that one line in newinstall.sh to set EUPS_VERSION to 2.1.4.
I made it most of the way through building lsst_distrib but failed here:
[ 100/101 ] jointcal master-gc935ebf72c+5 ...
***** error: from /nfs/farm/g/desc/u1/software/redhat6-x86_64-64bit-devtoolset-3/DMstack/w_2017_26_py3_2/stack/miniconda3-4.2.12-7c8e67/EupsBuildDir/Linux64/jointcal-master-gc935ebf72c+5/build.log:
ERROR: setUpClass (__main__.UtilsBinaryTester)
Traceback (most recent call last):
File "/nfs/farm/g/desc/u1/software/redhat6-x86_64-64bit-devtoolset-3/DMstack/w_2017_26_py3_2/stack/miniconda3-4.2.12-7c8e67/Linux64/utils/13.0-6-g7b92220/python/lsst/utils/tests.py", line 198, in setUpClass
raise Exception("No executables discovered.")
Exception: No executables discovered.
Ran 0 tests in 0.001s
The following tests failed:
1 tests failed
scons: *** [checkTestStatus] Error 1
scons: building terminated because of errors.
+ exit -4
eups distrib: Failed to build jointcal-master-gc935ebf72c+5.eupspkg: Command:
source "/nfs/farm/g/desc/u1/software/redhat6-x86_64-64bit-devtoolset-3/DMstack/w_2017_26_py3_2/eups/2.1.4/bin/setups.sh"; export EUPS_PATH="/nfs/farm/g/desc/u1/software/redhat6-x86_64-64bit-devtoolset-3/DMstack/w_2017_26_py3_2/stack/miniconda3-4.2.12-7c8e67"; (/nfs/farm/g/desc/u1/software/redhat6-x86_64-64bit-devtoolset-3/DMstack/w_2017_26_py3_2/stack/miniconda3-4.2.12-7c8e67/EupsBuildDir/Linux64/jointcal-master-gc935ebf72c+5/build.sh) >> /nfs/farm/g/desc/u1/software/redhat6-x86_64-64bit-devtoolset-3/DMstack/w_2017_26_py3_2/stack/miniconda3-4.2.12-7c8e67/EupsBuildDir/Linux64/jointcal-master-gc935ebf72c+5/build.log 2>&1 4>/nfs/farm/g/desc/u1/software/redhat6-x86_64-64bit-devtoolset-3/DMstack/w_2017_26_py3_2/stack/miniconda3-4.2.12-7c8e67/EupsBuildDir/Linux64/jointcal-master-gc935ebf72c+5/build.msg
exited with code 252
I can provide the build log if it’s helpful. Is there an expectation that I should be using a more recent weekly to take advantage of this new eups?
Ok I’ll try to carry on with this build, and toss in lsst_sims. That way we can carry on testing the new features offered by eups. I’ll just note that I’ve built this weekly of lsst_distrib successfully on the same machine without any complaints from jointcal. The only difference is my move to the latest eups.
If you can demonstrate that repeatedly that would be really useful. EUPS shouldn’t have any impact on a particular build since none of the packages depend on EUPS when they are being built. If switching between 2.1.3 and 2.1.4 is the difference between jointcal building and not building then I need to investigate.
The failure was the same as heather999 listed above: test failed, "No executables discovered."
Please see my previous post above.
Maybe it’s not directly related, but after setting opt to 1, the installation completed without errors.