Setting qemu task to invalid per Colins explanation that the LP case
doesn't use it.
** Changed in: qemu (Ubuntu)
Status: Confirmed => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Interesting, so somewhat the system is triggering an illegal arm64
instruction? Can be that gdb needs somebody telling it to use armhf
platform?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1707409
qemu isn't involved. We intentionally run armhf builds on an arm64
kernel (with an appropriate personality set) because this allows us to
make denser use of our build resources; I don't expect this to change.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which
Well, LP builders have qemu 2.5, so this might be true for the syscall.
However, I appreciate the first point, this is in-line with my
expectations and might be solvable by launchpad buildd team admins.
Can you please have a deeper look now?
thanks!
--
You received this bug notification
** Changed in: launchpad-buildd
Status: Invalid => New
** Changed in: linux (Ubuntu)
Status: Incomplete => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1707409
Title:
There is two issues being mixed up here
1) launchpad buildd changes.
notmuch build system appears to be confused by the new enviroment. It
appears ubuntu has chosen "armhf chroot on arm64 machine" approach,
which would mean qemu system call emulation is not involved. if it is -
it a buildd
>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
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?
