I have tried installing it on my laptop which runs 20.04.1-Ubuntu and also on a Uni computer which runs Centos. It fails both times at the same place. Any help that you can provide would be most welcome.
tests/test_cliCmdQueryDimensionRecords.py:78:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
python/lsst/daf/butler/tests/utils.py:142: in assertAstropyTablesEqual
self.assertTrue(report_diff_values(table, expected, fileobj=diff), msg="\n" + diff.getvalue())
E AssertionError: False is not true :
E a> instrument id physical_filter ... zenith_angle region timespan
E ? -- ^
E b> instrument id physical_filter ... zenith_angle region timespan [2]
E ? ^^^
E ------------ --- --------------- ... ------------ ------ ------------
E DummyCamComp 423 d-r ... None None None .. None
E DummyCamComp 424 d-r ... None None None .. None
This is what you get when you are using a new astropy with an old pipelines release. It looks like you are using the 4.0.0 rubin-env and that environment only works for newer weekly releases. The old v23 release is based on a conda-forge rubin environment from last year and you must use that environment to build v23.
How did you get your newinstall.sh file? The instructions say to download the 23_0_2 version and using that you should get the correct environment. If you downloaded newinstall.sh from main then it will be too new for you.
Sorry, it looks like there was a problem in our release process and the wrong version of newinstall.sh got tagged for 23.0.2. Please use the version for 23.0.1 instead in the meantime.
Hello K-T Lim,
I tried the 23.0.1 release and it fails at the same point in the installation. I tried an earlier release (22.0.1) and the installation fails much earlier in the process.
Which conda environment did it install? (ie which version of rubin-env is it using?). The rubin-env for 23.0.1 installs should be using v0.8.1 which should pin astropy.
I am reminded that we don’t pin the astropy version in the rubin-env used by v23. We had back-ported the fix to support both astropy v4 and v5 but that is in the v23.0.3 release candidate that should be coming out at some point.
Is there a reason why you can’t use a newer release? v23 is derived from the codebase as it was back in October 2021. The v24.0 release is going to be based on the w_2022_28 tag so you should be safe installing that weekly and using it instead of v23.
Where you currently ask for v23_0_2 from eups distrib install you instead ask for w_2022_28. You will need to have the 4.x rubin-env (which is what you will get from the main branch for newinstall.sh)
tests/maskedImage
tests/maskedImage: symbol lookup error: /home/plah/programs/lsst_stack/stack/miniconda3-py38_4.9.2-4.0.0/EupsBuildDir/Linux64/afw-gba47b54d5d+94dc90c3ea/afw-gba47b54d5d+94dc90c3ea/lib/libafw.so: undefined symbol: _Py_Dealloc
It seems that a recent change to how linking worked in the conda infrastructure exposed a bug that we fixed on DM-35600. You will have to use at least w_2022_30 to get the build to go past that.
@yusra I think we will have to back-port that ticket to the v24 release.
and got to [ 46/84 ] before getting an error which halted installation. The exact error message is:
[ 46/84 ] meas_base gcf00a76f74+12dc3af6bc …
***** error: from /home/plah/programs/lsst_stack/stack/miniconda3-py38_4.9.2-4.0.0/EupsBuildDir/Linux64/meas_base-gcf00a76f74+12dc3af6bc/build.log:
Coverage XML written to file tests/.tests/pytest-meas_base.xml-cov-meas_base.xml
============================= slowest 5 durations ==============================
20.95s call tests/test_GaussianFlux.py::GaussianFluxTestCase::testMonteCarlo
2.41s call tests/test_SdssShape.py::SdssShapeTestCase::testMonteCarlo
2.15s call tests/test_ScaledApertureFlux.py::ScaledApertureFluxTestCase::testApertureTruncated
2.01s call tests/test_PsfFlux.py::PsfFluxTestCase::testMonteCarlo
1.89s call tests/test_SdssCentroid.py::SdssCentroidTestCase::testMonteCarlo
=========================== short test summary info ============================
FAILED tests/test_diaCalculationPlugins.py::TestSkewDiaPsFlux::testCalculate
================= 1 failed, 256 passed, 73 warnings in 30.70s ==================
Global pytest run: failed with 1
Failed test output:
Global pytest output is in /home/plah/programs/lsst_stack/stack/miniconda3-py38_4.9.2-4.0.0/EupsBuildDir/Linux64/meas_base-gcf00a76f74+12dc3af6bc/meas_base-gcf00a76f74+12dc3af6bc/tests/.tests/pytest-meas_base.xml.failed
The following tests failed:
/home/plah/programs/lsst_stack/stack/miniconda3-py38_4.9.2-4.0.0/EupsBuildDir/Linux64/meas_base-gcf00a76f74+12dc3af6bc/meas_base-gcf00a76f74+12dc3af6bc/tests/.tests/pytest-meas_base.xml.failed
1 tests failed
scons: *** [checkTestStatus] Error 1
scons: building terminated because of errors.
This is DM-35777. Rather than trying to pick the oldest weekly that might possibly work (to keep you as close to v23 as we can) you should pick something very new like w_2022_35 (or _36 if that’s out).
Thanks for reporting the v23 build problem. We will have to backport the butler test fix to 23.0.3 or pin astropy in that conda env.