Re: Bug#1114618: FTBFS against Octave 10

[Rafael Laboissière <rafael@debian.org>]

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

> Le mardi 09 septembre 2025 à 16:14 +0200, Rafael Laboissière a écrit :
> > * Sébastien Villemot <sebastien@debian.org> [2025-09-09 11:40]:
> >
> > > Le mardi 09 septembre 2025 à 11:25 +0200, Rafael Laboissière a écrit :
> > > > * Sébastien Villemot <sebastien@debian.org> [2025-09-09 10:20]:
> > > >
> > > > > Le mardi 09 septembre 2025 à 09:39 +0200, Rafael Laboissière a écrit :
> > > > > > * Sébastien Villemot <sebastien@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