Lsst_distrib install failure on verify 93/128

Support
,
#1

I’m trying to install the stack on a “linux subsystem for windows” running Ubuntu 18.04.3 following the instructions here: https://pipelines.lsst.io/install/newinstall.html
I opted to use the miniconda package rather than my system python install.
When I run eups distrib install -t v18_1_0 lsst_distrib it runs up to step 93/128 and then fails to build giving a long error message which is contained at the bottom in the attached build.log file.
I’ve checked the prerequisites and it seems like everything is installed correctly, but I definitely could’ve missed something. Any idea where I’ve gone wrong?

build.log (1.8 MB)

pytest-verify.xml.failed (9.5 KB)

#2

The test failures are:

[gw2] linux -- Python 3.7.2 /home/beemartin/lsst_stack/python/miniconda3-4.5.12/envs/lsst-scipipe-1172c30/bin/python3.7

self = <test_commonMetrics.TimingMetricTestSuite testMethod=testValid>

    def testValid(self):
        result = self.task.run([self.scienceTask.getFullMetadata()])
        meas = result.measurement
    
        self.assertIsInstance(meas, Measurement)
        self.assertEqual(meas.metric_name, Name(metric=self.config.metric))
>       self.assertGreater(meas.quantity, 0.0 * u.second)
E       AssertionError: <Quantity 0. s> not greater than <Quantity 0. s>

tests/test_commonMetrics.py:79: AssertionError
_______________________ TimingMetricTestSuite.testValid ________________________
[gw1] linux -- Python 3.7.2 /home/beemartin/lsst_stack/python/miniconda3-4.5.12/envs/lsst-scipipe-1172c30/bin/python3.7

self = <test_commonMetrics.TimingMetricTestSuite testMethod=testValid>

    def testValid(self):
        result = self.task.run([self.scienceTask.getFullMetadata()])
        meas = result.measurement
    
        self.assertIsInstance(meas, Measurement)
        self.assertEqual(meas.metric_name, Name(metric=self.config.metric))
>       self.assertGreater(meas.quantity, 0.0 * u.second)
E       AssertionError: <Quantity 0. s> not greater than <Quantity 0. s>

@kfindeisen could this be some oddity of Windows not properly getting the execution time?

#3

It might be; the times ultimately come from resource.getrusage. It might not work at all on Windows, given that it’s supposed to be an export of a Unix function.

EDIT: sorry, was distracted in my initial reply. If this is a Unix VM running on Windows, then I’d expect getrusage to work.

#4

Is there a way I could test this function? It seems like other people have gotten past this step in the install process using WSL (see linked post), albeit on a different, earlier version of Ubuntu.

#5

Oops, my mistake. The time being used in that test actually comes from time.process_time.

You can test it (as well as the key line of the failed test) by starting up python in a console window on the Ubuntu side and trying something like:

from time import process_time, sleep
process_time()
sleep(0.4)
process_time()
#6

hmm, using the miniconda python from the install, that seems to work fine
Output:
0.078125
0.109375