Bug#1114618: FTBFS against Octave 10

[Sébastien Villemot]

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?

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

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄⠀⠀⠀⠀  https://www.debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/debian-science-maintainers/attachments/20250909/c5ca5455/attachment.sig>