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? > > 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
Attachment:
signature.asc
Description: This is a digitally signed message part