On 9/10/25 23:48, Bastien Roucaries wrote:
Le mercredi 10 septembre 2025, 22:40:59 heure d’été d’Europe centrale Jérémy
Lal a écrit :
Le mer. 10 sept. 2025 à 21:49, Simon Josefsson <[email protected]> a
écrit :
Hi. Recent NSD support XDP and install some eBPF *.o files. Upstream
puts them in /usr/share/nsd/ which lintian complains about.
E: nsd: arch-dependent-file-in-usr-share
[usr/share/nsd/xdp-dns-redirect_kern.o]
N:
N: This package installs an ELF binary in the /usr/share hierarchy,
which is
N: reserved for architecture-independent files.
Where is the appropriate place for these files? I tried
/usr/libexec/nsd/ instead but got:
E: nsd: binary-from-other-architecture
[usr/libexec/nsd/xdp-dns-redirect_kern.o]
N:
N: This ELF binary appears to have been built for an architecture other
than
N: the one of the binary package being tested. This may occur when a
N: pre-built binary is shipped in the package or when an attempt to
N: cross-compile didn't work.
FWIW, file(1) on such objects (built on amd64) says:
xdp-dns-redirect_kern.o: ELF 64-bit LSB relocatable, eBPF, version 1
(SYSV), with debug_info, not stripped
Should we use /usr/lib/nsd?
/usr/lib/x86_64-linux-gnu/nsd/?
/usr/lib/bpf/?
/usr/lib/bpf/nsd/?
/usr/lib/x86_64-linux-gnu/bpf/?
/usr/lib/x86_64-linux-gnu/bpf/nsd/?
Not a specialist, but eBPF ELF files are bytecode for a virtual machine...
I'm interested in the correct answer, because somehow it's related to WASM.
Talk to this a debian multiarch BoF at debian, it is a virual so we must create
a arch triplet for this, it is likely a candidate for an specific arch none
long term.
for me it is ebpf-none-v1 or
so /usr/lib/ebpf-none-v1/
the shortest triplet is bpf, also used by the GNU toolchain. Why would
there be a reason to version these at this point?
