Kernel version: Linux kishi10 3.2.0-98-highbank #138-Ubuntu SMP PREEMPT Mon Jan 11 13:24:41 UTC 2016 armv7l
Kernel version: Linux bos01-arm64-024 4.2.0-42-generic #49-Ubuntu SMP Tue Jun 28 21:24:20 UTC 2016 aarch64
so, in the first case armhf was ran on top of an armv7 kernel, in the other case it became an arm64 one
this might not even be a regression in qemu/kvm, but rather a change in buildd system that spot a new bug
doing a xenial build failed aswell, so I presume this is not a toolchain regression (also because it works fine on real HW), but a qemu/linux bug.
Hello, after spending a lot of time debugging notmuch failure under armhf, we came to a conclusion:
it started to fail when the infra moved to a new kernel 3.2 to a 4.2, and moved under qemu/kvm environment.
the latest successful build is here created on 2016-03-13 https:/ /launchpad. net/ubuntu/ +source/ notmuch/ 0.21-3ubuntu2/ +build/ 9344826
and the first bad is this one: Started on 2016-08-31 https:/ /launchpad. net/ubuntu/ +source/ notmuch/ 0.22.1- 2ubuntu1/ +build/ 10600002
Kernel version: Linux kishi10 3.2.0-98-highbank #138-Ubuntu SMP PREEMPT Mon Jan 11 13:24:41 UTC 2016 armv7l
Kernel version: Linux bos01-arm64-024 4.2.0-42-generic #49-Ubuntu SMP Tue Jun 28 21:24:20 UTC 2016 aarch64
so, in the first case armhf was ran on top of an armv7 kernel, in the other case it became an arm64 one
this might not even be a regression in qemu/kvm, but rather a change in buildd system that spot a new bug
doing a xenial build failed aswell, so I presume this is not a toolchain regression (also because it works fine on real HW), but a qemu/linux bug.
I did run the test under strace/valgrind, I can't do much more testing, but I hope the logs can be useful for you /launchpad. net/~costamagna gianfranco/ +archive/ ubuntu/ locutusofborg- ppa/+build/ 13169431 /launchpad. net/~costamagna gianfranco/ +archive/ ubuntu/ locutusofborg- ppa/+build/ 13169431
https:/
https:/
You can see the strace/valgrind outputs between "BEGIN" and "END" keywords