Both urdfdom and urdfdom_headers are now in testing. On Tue, Feb 17, 2026 at 8:47 PM Jose Luis Rivero <[email protected]> wrote:
> 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. >
