Hi, On 2025-12-04 08:49, Paul Gevers wrote: > user [email protected] > usertag riscv64 > thanks > > Hi, > > On 12/4/25 05:33, Bas Couwenberg wrote: > > Please help satpy migrate to testing, the autopkgtest failures on riscv64 & > > s390x are not regressions, but are not detected as such. > > > The package got removed from testing, so the package is considered new. For > new packages, any failure is preventing migration. I'll ignore the s390x > failure as that's a test dependency that can't be installed there > (python3-satpy is arch:all and can be installed, but not all its > Recommends). The riscv64 failure should be investigated as that seems to > point out a genuine issue (which of course can be a bad test, but then > fixing the test is the proper course of action). Adding riscv64 porters for > that.
This is indeed a real issue. The conversion of a NaN to an int is undefined. It appears to be 0 on most CPUs, but it is not the case on riscv64. The issue is actually already known upstream: https://github.com/pytroll/satpy/issues/2934 The following patch fixes the issue on riscv64. It also removes the warning on other architectures. --- satpy-0.59.0.orig/satpy/enhancements/colormap.py +++ satpy-0.59.0/satpy/enhancements/colormap.py @@ -41,9 +41,10 @@ def lookup(img, **kwargs): @on_separate_bands @using_map_blocks def _lookup_table(band_data, luts=None, index=-1): - # NaN/null values will become 0 lut = luts[:, index] if len(luts.shape) == 2 else luts - band_data = band_data.clip(0, lut.size - 1).astype(np.uint8) + band_data = band_data.clip(0, lut.size - 1) + # Convert to uint8, with NaN/null values changed into 0 + band_data = np.nan_to_num(band_data).astype(np.uint8) return lut[band_data] Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B [email protected] http://aurel32.net
signature.asc
Description: PGP signature
