On Mon, Feb 16, 2026 at 12:15:40PM +0100, Emilio Pozuelo Monfort wrote: > On 12/02/2026 18:00, Jose Luis Rivero wrote: > > Hello Paul, Adrian: > > > > On Thu, Feb 12, 2026 at 12:54 PM Adrian Bunk <[email protected]> wrote: > > > > > On Thu, Feb 12, 2026 at 12:40:11PM +0100, Paul Gevers wrote: > > > > ... > > > > On 2/7/26 23:09, Jose Luis Rivero wrote: > > > > > Thanks Emilio. Packages uploaded to the unstable. > > > > > > > > > > > > There seems to be regressions on riscv64 in several autopkgtest. Can you > > > > have a look: > > > > > > > > /usr/bin/riscv64-linux-gnu-ld.bfd: cannot find -lurdfdom_model_state: No > > > > such file or directory > > > > > > This isn't riscv64 specific, see for example > > > https://ci.debian.net/packages/r/ros-kdl-parser/testing/amd64/68547339/ > > > > > > This is a variant of the usual issue that different so-versions of a > > > library should ideally conflict with each other, since mixing them > > > in a binary is in many cases not safe. > > > > Thanks Adrian for providing context. Should I go ahead and declare a > > conflict in > > liburdfdom5 agains the liburdfdom4? Or do we prefer it to hable in a > > different way? > > I have added a hint to britney to ignore that issue. I'm not sure why having > multiple libs loaded into an executable would add a linker -l flag,
As said, "a variant of". > when that should (ideally) be controlled by pkg-config files. It is controlled by CMake files, which provide the same functionality as pkg-config files but also hardcode many such details. In this case the CMake files of liburdf-dev/testing were hardcoding implementation details of liburdfdom-dev/testing that were no longer correct with liburdfdom-dev/sid. > Emilio cu Adrian
