Bug#1114618: FTBFS against Octave 10

[Rafael Laboissière]

* Sébastien Villemot <sebastien at debian.org> [2025-09-09 16:51]:

> Le mardi 09 septembre 2025 à 16:14 +0200, Rafael Laboissière a écrit :
>> * Sébastien Villemot <sebastien at debian.org> [2025-09-09 11:40]:
>>
>>> Le mardi 09 septembre 2025 à 11:25 +0200, Rafael Laboissière a écrit :
>>>> * Sébastien Villemot <sebastien at debian.org> [2025-09-09 10:20]:
>>>>
>>>>> Le mardi 09 septembre 2025 à 09:39 +0200, Rafael Laboissière a écrit :
>>>>>> * Sébastien Villemot <sebastien at debian.org> [2025-09-08 21:01]:
>>>>>>
>>>>>> […]
>>>>>>> Le lundi 08 septembre 2025 à 19:43 +0200, Sébastien Villemot a écrit :
>>>>>>>
>>>>>>> Actually fixing #1061644 would fix the present FTBFS bug and all the 
>>>>>>> similar ones.
>>>>>>>
>>>>>>> Should I go ahead?
>>>>>>
>>>>>> If the fix consists in adding a file to /etc/ld.so.conf.d/, like the 
>>>>>> torsocks package does¹, I guess it will make Lintian unhappy.²
>>>>>
>>>>> Yes, that would be the plan. And that would make dpkg-shlibdeps happy.
>>>>
>>>> Lintian classifies the package-modifies-ld.so-search-path tag as 
>>>> "type: error". Does this qualify the issue as release-critical?
>>>>
>>> I see. So adding a drop-in file under /etc/ld.so.conf.d/ is considered 
>>> bad practice and is discouraged.
>>>
>>> Actually there is no real need to tell the dynamic linker to look for 
>>> this additional directory, because as I said before, the .mex files are 
>>> being loaded from within Octave and liboctmex is already in memory.
>>>
>>> So an alternative fix is just to tell dpkg-shlibdeps to stop 
>>> complaining, by passing it the -l option.
>>
>> Ok, I implemented the idea in vlfeat:
>>
>> https://salsa.debian.org/science-team/vlfeat/-/commit/451505636550205a60c362aed32c0dc8c324f1fa 
>> https://salsa.debian.org/science-team/vlfeat/-/commit/5dba6d243590025e59a078f25462ceb5e1cd5abc
>
> Sounds good. But does that mean that vlfeat cannot take advantage of 
> your fix in dh-octave?

No, vlfeat cannot take advantage of the fix in dh-octave because it 
does not use the Octave sequence of Debhelper.

>>> Ideally this would be done by dh-octave, so that we don’t have to 
>>> modify all individual packages, but I don’t know whether this is 
>>> possible.
>>
>> I implemented a solution in dh-octave: 
>> https://salsa.debian.org/pkg-octave-team/dh-octave/-/commit/e7497ed114bcf89ccde18ef97ed20f064f17d26f
>>
>> It seems to be working correctly.
>>
>> How should we proceed? I could release the package with the above fix to 
>> experimental. Once the tests are complet, you can merge the bug reports 
>> that are related to the dpkg-shlibdeps issue and release a new version of 
>> dh-octave to unstable, and close the bugs. Is this an acceptable plan?
>
> Thanks for making the change in dh-octave!
>
> I suggest that you upload the new dh-octave directly to unstable. This 
> should not break anything with Octave 9, unless I’m missing something.
>
> Then we will review bugs individually to check whether they are fixed 
> or not by this upload (I think that dynare will need a custom fix, 
> maybe vlfeat also if I understand your above commits correctly), and 
> directly close those that are indeed fixed by the new dh-octave. So we 
> should probably not merge all the bugs.

Ok, I will upload a new version of dh-octave to unstable as soon as 
possible (probably tomorrow).

I will also take care of vlfeat.

Best,

Rafael