I agree on 384 being getrandom and there are other cases like [1].
I don't know details but would consider the pure lack of the system call support a feature request to upstream qemu.
We could add a qemu upstream task here for that FR - in the worst case we are told why we are wrong - opinions?
On the case itself for now I'd recommend to get back the section:
ifeq ($(DEB_HOST_ARCH),armhf)
TERM=vt100 dh_auto_test || true
I agree on 384 being getrandom and there are other cases like [1].
I don't know details but would consider the pure lack of the system call support a feature request to upstream qemu.
We could add a qemu upstream task here for that FR - in the worst case we are told why we are wrong - opinions?
On the case itself for now I'd recommend to get back the section: HOST_ARCH) ,armhf)
ifeq ($(DEB_
TERM=vt100 dh_auto_test || true
Which maybe was there for similar reasons.
[1]: https:/ /users. rust-lang. org/t/missing- system- calls-when- running- tests-under- qemu-arm- at-travisci/ 5013