On 3/29/26 1:01 PM, Antonio Valentino wrote:
Il 29/03/26 09:54, Sebastiaan Couwenberg ha scritto:
On 3/28/26 5:29 PM, Antonio Valentino wrote:
Il 28/03/26 16:57, Antonio Valentino ha scritto:
Dear Bas,
Il 27/03/26 13:29, Sebastiaan Couwenberg ha scritto:
On 3/26/26 7:34 PM, Sebastiaan Couwenberg via Pkg-grass-devel wrote:
The CI pipeline for this change is failing repeatedly.
The build on i386 succeeds which suggests that we should skip
test_Sentinel1SarProduct more broadly to not get the test killed, on my local
system with more resources than Salsa CI the test succeeds.
I think we should skip it also when CI=true is set in the environment as done
by GitLab CI, or maybe even unconditionally.
What are your thoughts?
I've got a patch now that skips the test on 32-bit architectures or when less
than 8 GB memory is available.
The Salsa CI runners have less than 8, and the GitHub Actions runners have 16
GB total which explains why the test doesn't get killed there.
I'm looking at it right now.
The problem should be only linked to "SLC" products for which a kind mosaic of
performed internally via `xarray.concat`.
Apparently the use of such function is currently no lazy (although it could,
see [1]) so the entire dataset is materialized in memory.
Luckily if dask is available the computation is still done in a lazy way.
My suggestion is to add dask as build dependency (only for testing).
It should hopefully solve the memory erro in CI.
I'm going to make a test on my fork.
[1] https://github.com/pydata/xarray/issues/4628
cheers
Apparently it works:
https://salsa.debian.org/antonio.valentino/sarsen/-/pipelines/1054701
That looks like a better solution, although the dask dependency may be a bit
problematic as the package hasn't been updated in over a year and IIRC those
tend to break rdeps.
dask is quite a common dependency in your packages so you're likely used to
that already.
You are right.
Maybe I could keep the patch in the debian folder but disabled (i.e. not in
d/patches/Series) so that we can quickly switch to it and drop the dependency
on dask in case it starts breaking again.
what do you think?
Just revert my change and merge yours, my change can be cherry-picked from the
history when dask needs to be dropped in the future.
Kind Regards,
Bas
--
PGP Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
_______________________________________________
Pkg-grass-devel mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-grass-devel
