Hi,
On 2025-12-04 08:49, Paul Gevers wrote:
> user debian-riscv@lists.debian.org
> 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
aurelien@aurel32.net http://aurel32.net
Attachment:
signature.asc
Description: PGP signature