On Mon, Feb 16, 2026 at 12:36 PM Adrian Bunk <[email protected]> wrote:
> 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". Thanks all for the help. urdfdom is now in testing and urdfdom_headers will probably land tomorrow.
