Bug#1114618: FTBFS against Octave 10

Rafael Laboissière rafael at debian.org
Tue Sep 9 15:14:39 BST 2025


* 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

> 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?

Best,

Rafael Laboissière



More information about the debian-science-maintainers mailing list