>I agree on 384 being getrandom and there are other cases like [1].
I did the same research :)
>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?
yes please!
>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
>
>Which maybe was there for similar reasons.
>I agree on 384 being getrandom and there are other cases like [1].
I did the same research :)
>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?
yes please!
>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.
I think this used to hang the builders, IIRC, but seems to pass now /launchpadlibra rian.net/ 332584378/ buildlog_ ubuntu- artful- armhf.notmuch_ 0.25-4ubuntu1_ BUILDING. txt.gz
https:/
uploaded in artful
G.