[Git][debian-gis-team/sarsen][master] Enable build profile CI job.

[Sebastiaan Couwenberg]

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