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

[Antonio Valentino]

Dear Bas,

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?

kind regards
-- 
Antonio Valentino