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 Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.
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 Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bu
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 Kernel
Packages, whic
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 becaus
** 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 Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1707409
Tit
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 config
>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?
8 matches
Mail list logo