<div dir="auto">Thank you all for volunteering. I can try to help out as well with any of the programming/integration issues, but would need some hand-holding with regards to packaging. (To date myself, the last time I built a Debian package was on Woody, and I seem to recall the process involved running ./debian/rules by hand).<div dir="auto"><br></div><div dir="auto">How do we get some of these outstanding CVEs cleared? </div><div dir="auto"><br></div><div dir="auto">R/Eric</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, Aug 3, 2026, 4:56 AM Simon Richter <<a href="mailto:sjr@debian.org">sjr@debian.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
On 8/3/26 4:09 PM, Timo Aaltonen wrote:<br>
<br>
> /usr/bin/x86_64-linux-gnu-ld.bfd: /usr/lib/x86_64-linux-gnu/ <br>
> libkeyutils.so.1: error adding symbols: DSO missing from command line<br>
<br>
This should be fairly simple to work around.<br>
<br>
The error message means that the object being built has an undefined <br>
symbol that is satisfied by libkeyutils.so.1, but this library is only <br>
part of the link because another library depends on it, and it has not <br>
been explictly mentioned.<br>
<br>
If the object uses an interface from that library, it should be added as <br>
a proper dependency, but if it uses something like an inline function <br>
indirectly through another library, that library needs to be updated to <br>
communicate the information "consumers of this library also need to link <br>
against this other library" (which is possible using libtool .la files <br>
or CMake definitions, although for some reason Debian believes one of <br>
these to be a bad interface).<br>
<br>
In any case, explicitly adding the library to the link should make the <br>
problem go away.<br>
<br>
    Simon<br>
<br>
</blockquote></div>