python-pywt failed to build from source in Fedora rawhide/f36 https://koji.fedoraproject.org/koji/taskinfo?taskID=81985713 For details on the mass rebuild see: https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild Please fix python-pywt at your earliest convenience and set the bug's status to ASSIGNED when you start fixing it. If the bug remains in NEW state for 8 weeks, python-pywt will be orphaned. Before branching of Fedora 37, python-pywt will be retired, if it still fails to build. For more details on the FTBFS policy, please visit: https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/
Created attachment 1856338 [details] build.log file build.log too big, will only attach last 32768 bytes
Created attachment 1856339 [details] root.log file root.log too big, will only attach last 32768 bytes
Created attachment 1856340 [details] state.log
This bug appears to have been reported against 'rawhide' during the Fedora 36 development cycle. Changing version to 36.
This fails on aarch64 and ppc64le. With different failures. aarch64: ____________________________ test_cwt_batch[0-fft] _____________________________ axis = 0, method = 'fft' @pytest.mark.parametrize('axis, method', product([0, 1], ['conv', 'fft'])) def test_cwt_batch(axis, method): dtype = np.float64 time, sst = pywt.data.nino() n_batch = 8 batch_axis = 1 - axis sst1 = np.asarray(sst, dtype=dtype) sst = np.stack((sst1, ) * n_batch, axis=batch_axis) dt = time[1] - time[0] wavelet = 'cmor1.5-1.0' scales = np.arange(1, 32) # non-batch transform as reference [cfs1, f] = pywt.cwt(sst1, scales, wavelet, dt, method=method, axis=axis) shape_in = sst.shape [cfs, f] = pywt.cwt(sst, scales, wavelet, dt, method=method, axis=axis) # shape of input is not modified assert_equal(shape_in, sst.shape) # verify same precision assert_equal(cfs.real.dtype, sst.dtype) # verify expected shape assert_equal(cfs.shape[0], len(scales)) assert_equal(cfs.shape[1 + batch_axis], n_batch) assert_equal(cfs.shape[1 + axis], sst.shape[axis]) # batch result on stacked input is the same as stacked 1d result > assert_equal(cfs, np.stack((cfs1,) * n_batch, axis=batch_axis + 1)) E AssertionError: E Arrays are not equal E E Mismatched elements: 61080 / 65472 (93.3%) E Max absolute difference: 2.3052588782060247e-15 E Max relative difference: 4.507026999251287e-14 E x: array([[[ 0.004042+0.026095j, 0.004042+0.026095j, 0.004042+0.026095j, E ..., 0.004042+0.026095j, 0.004042+0.026095j, 0.004042+0.026095j], E [-0.005609+0.012741j, -0.005609+0.012741j, -0.005609+0.012741j,... E y: array([[[ 0.004042+0.026095j, 0.004042+0.026095j, 0.004042+0.026095j, E ..., 0.004042+0.026095j, 0.004042+0.026095j, 0.004042+0.026095j], E [-0.005609+0.012741j, -0.005609+0.012741j, -0.005609+0.012741j,... pywt/tests/test_cwt_wavelets.py:406: AssertionError ____________________________ test_cwt_batch[1-fft] _____________________________ axis = 1, method = 'fft' @pytest.mark.parametrize('axis, method', product([0, 1], ['conv', 'fft'])) def test_cwt_batch(axis, method): dtype = np.float64 time, sst = pywt.data.nino() n_batch = 8 batch_axis = 1 - axis sst1 = np.asarray(sst, dtype=dtype) sst = np.stack((sst1, ) * n_batch, axis=batch_axis) dt = time[1] - time[0] wavelet = 'cmor1.5-1.0' scales = np.arange(1, 32) # non-batch transform as reference [cfs1, f] = pywt.cwt(sst1, scales, wavelet, dt, method=method, axis=axis) shape_in = sst.shape [cfs, f] = pywt.cwt(sst, scales, wavelet, dt, method=method, axis=axis) # shape of input is not modified assert_equal(shape_in, sst.shape) # verify same precision assert_equal(cfs.real.dtype, sst.dtype) # verify expected shape assert_equal(cfs.shape[0], len(scales)) assert_equal(cfs.shape[1 + batch_axis], n_batch) assert_equal(cfs.shape[1 + axis], sst.shape[axis]) # batch result on stacked input is the same as stacked 1d result > assert_equal(cfs, np.stack((cfs1,) * n_batch, axis=batch_axis + 1)) E AssertionError: E Arrays are not equal E E Mismatched elements: 61080 / 65472 (93.3%) E Max absolute difference: 2.3052588782060247e-15 E Max relative difference: 4.507026999251287e-14 E x: array([[[ 0.004042+0.026095j, -0.005609+0.012741j, -0.004250+0.074014j, E ..., -0.012503-0.087315j, -0.010488+0.00735j , -0.008362+0.051594j], E [ 0.004042+0.026095j, -0.005609+0.012741j, -0.004250+0.074014j,... E y: array([[[ 0.004042+0.026095j, -0.005609+0.012741j, -0.004250+0.074014j, E ..., -0.012503-0.087315j, -0.010488+0.00735j , -0.008362+0.051594j], E [ 0.004042+0.026095j, -0.005609+0.012741j, -0.004250+0.074014j,... pywt/tests/test_cwt_wavelets.py:406: AssertionError ppc64le: ________________________ test_accuracy_precomputed_cwt _________________________ @uses_precomputed # skip this case if pymatbridge + Matlab are being used @pytest.mark.slow def test_accuracy_precomputed_cwt(): # Keep this specific random seed to match the precomputed Matlab result. rstate = np.random.RandomState(1234) # has to be improved epsilon = 2e-15 epsilon32 = 1e-5 epsilon_psi = 1e-15 for wavelet in wavelets: with warnings.catch_warnings(): warnings.simplefilter('ignore', FutureWarning) w = pywt.ContinuousWavelet(wavelet) w32 = pywt.ContinuousWavelet(wavelet,dtype=np.float32) psi = _load_matlab_result_psi(wavelet) _check_accuracy_psi(w, psi, wavelet, epsilon_psi) for N in _get_data_sizes(w): data = rstate.randn(N) data32 = data.astype(np.float32) scales_count = 0 for scales in _get_scales(w): scales_count += 1 coefs = _load_matlab_result(data, wavelet, scales_count) > _check_accuracy(data, w, scales, coefs, wavelet, epsilon) pywt/tests/test_matlab_compatibility_cwt.py:100: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ data = array([ -1.39349312e+00, 8.43433358e-01, -7.48389740e-01, 6.96962461e-01, -2.31877711e-02, 3.14787623e-....61324483e+00, -2.62751782e-03, 2.24986089e+00, -1.20909849e+00, 5.33308212e-02, 2.85267990e+00]) w = pywt._extensions._pywt.ContinuousWavelet(name='cgau1'), scales = 1 coefs = array([[ 5.88904952e-01 -4.22675773e-01j, -1.02734763e+00 +2.40005860e-02j, 5.28246856e-01 +1.4842....74440177e+00 +1.48754656e-01j, -7.16701910e-01 -1.17576867e+00j, -1.58277318e+00 +7.72076610e-01j]]) wavelet = 'cgau1', epsilon = 2e-15 def _check_accuracy(data, w, scales, coefs, wavelet, epsilon): # PyWavelets result coefs_pywt, freq = pywt.cwt(data, scales, w) # coefs from Matlab are from R2012a which is missing the complex conjugate # as shown in Eq. 2 of Torrence and Compo. We take the complex conjugate of # the precomputed Matlab result to account for this. coefs = np.conj(coefs) # calculate error measures err = coefs_pywt - coefs rms = np.real(np.sqrt(np.mean(np.conj(err) * err))) msg = ('[RMS > EPSILON] for Scale: %s, Wavelet: %s, ' 'Length: %d, rms=%.3g' % (scales, wavelet, len(data), rms)) > assert_(rms < epsilon, msg=msg) E AssertionError: [RMS > EPSILON] for Scale: 1, Wavelet: cgau1, Length: 1000, rms=0.398 pywt/tests/test_matlab_compatibility_cwt.py:161: AssertionError
*** Bug 2099086 has been marked as a duplicate of this bug. ***
This blocks many other packages. Following the FTBFS policy, asking for a needinfo.
for the record, with pywt updated to 1.3.0 is the error on ppc64le the same, I wonder if this is uncovering an numpy issue rather than one being contained in pywt ...
This also blocks some live spin currently.
> aarch64: > […] > E Mismatched elements: 61080 / 65472 (93.3%) > E Max absolute difference: 2.3052588782060247e-15 > E Max relative difference: 4.507026999251287e-14 Those are tiny differences. It looks like the upstream epsilon may just be a little too tight. > ppc64le: > […] > > assert_(rms < epsilon, msg=msg) > E AssertionError: [RMS > EPSILON] for Scale: 1, Wavelet: cgau1, Length: 1000, rms=0.398 That, on the other hand, is a large difference. Note that epsilon is 2e-15 here.
There is an issue open upstream about failures on ppc64le, although the exact problems reported there appear to be different: https://github.com/PyWavelets/pywt/issues/508
I've filed https://src.fedoraproject.org/rpms/python-pywt/pull-request/5. I think the i686 failure might be a sporadic failure with xvfb-run.
Closing since the package now builds from source, even if skipped tests perhaps still represent some real issues on ppc64le.