Hi,
I've some trouble with building mksh on PPC64 and PPC64LE. Very often it fails on PPC64 fails with:
FAIL ./check.t:heredoc-tmpfile-5 Description: Check that heredoc temp files aren't removed too soon or too late. Backgrounded subshell command with here doc unexpected stdout - first difference: line 1, char 1 (wanted 'A', got 'L' wanted: A hi B Left overs: * got: Left overs: * A hi B
sometimes it works perfect. Also I see sometimes a similar defect on PPC64LE at exactly the same check of the test suite of mksh.
All build systems seems to be based on qemu/kvm, nevertheless there seem to be some differences but how to detect those (virt-what does report nothing). Maybe it depends on the real host on which qemu-system-ppc64 or qemu-system-ppc64le will be executed. It could be a defect of qemu based on the hosting system.
Do we have some real PPC64 and/or PPC64LE irons in our build farm or all hosts based on qemu/kvm?
Werner
On Freitag, 24. November 2017, 07:59:50 CET wrote Dr. Werner Fink:
Hi,
I've some trouble with building mksh on PPC64 and PPC64LE. Very often it fails on PPC64 fails with:
FAIL ./check.t:heredoc-tmpfile-5 Description: Check that heredoc temp files aren't removed too soon or too late. Backgrounded subshell command with here doc unexpected stdout - first difference: line 1, char 1 (wanted 'A', got 'L' wanted: A hi B Left overs: * got: Left overs: * A hi B
sometimes it works perfect. Also I see sometimes a similar defect on PPC64LE at exactly the same check of the test suite of mksh.
All build systems seems to be based on qemu/kvm, nevertheless there seem to be some differences but how to detect those (virt-what does report nothing). Maybe it depends on the real host on which qemu-system-ppc64 or qemu-system-ppc64le will be executed. It could be a defect of qemu based on the hosting system.
Do we have some real PPC64 and/or PPC64LE irons in our build farm or all hosts based on qemu/kvm?
all builds are chained in KVM.
You may check the "osc jobhistory" to see if you can see a pattern which host works and which not.
Hi Werner!
On 11/24/2017 07:59 AM, Dr. Werner Fink wrote:
I've some trouble with building mksh on PPC64 and PPC64LE. Very often it fails on PPC64 fails with: (snip) sometimes it works perfect. Also I see sometimes a similar defect on PPC64LE at exactly the same check of the test suite of mksh.
All build systems seems to be based on qemu/kvm, nevertheless there seem to be some differences but how to detect those (virt-what does report nothing). Maybe it depends on the real host on which qemu-system-ppc64 or qemu-system-ppc64le will be executed. It could be a defect of qemu based on the hosting system.
This could actually be true provided that OBS actually builds on QEMU and not really iron. Looking at the build logs for mksh for ppc64 [1] and ppc64el [2] in Debian, I don't see this particular testsuite failure in any of the builds in the history.
And, knowing Thorsten Glaser, the upstream developer, personally, I am very confident he would have spotted and fixed such a failure immediately. It might also be a good idea to contact Thorsten direcly as he is always interested in bug reports and fixing the bugs.
Do we have some real PPC64 and/or PPC64LE irons in our build farm or all hosts based on qemu/kvm?
If you don't happen to get access from someone at SUSE, I will be happy to provide you with an account on a powerpc (32-bit) or ppc64 (64-bit, big- endian) porterbox running Debian unstable. I have also an instance running openSUSE Tumbleweed ppc64.
If you need access to a ppc64el machine, I could help you getting in touch with people from IBM who I happen to know through Debian.
Cheers, Adrian
[1] https://buildd.debian.org/status/logs.php?pkg=mksh&arch=ppc64 [2] https://buildd.debian.org/status/logs.php?pkg=mksh&arch=ppc64el
On 11/24/2017 11:25 AM, John Paul Adrian Glaubitz wrote:> This could actually be true provided that OBS actually builds on QEMU and not
really iron. Looking at the build logs for mksh for ppc64 [1] and ppc64el [2] in Debian, I don't see this particular testsuite failure in any of the builds in the history.
Forgot to mention: Debian always uses real hardware for the build machines. The build maintainers and release managers have agreed (not sure whether there is also an official policy) that packages built with QEMU may not be uploaded to the archive.
Adrian
On Nov 24 2017, John Paul Adrian Glaubitz adrian.glaubitz@suse.com wrote:
Forgot to mention: Debian always uses real hardware for the build machines. The build maintainers and release managers have agreed (not sure whether there is also an official policy) that packages built with QEMU may not be uploaded to the archive.
KVM is also real hardware.
Andreas.
On 11/27/2017 10:31 AM, Andreas Schwab wrote:
Forgot to mention: Debian always uses real hardware for the build machines. The build maintainers and release managers have agreed (not sure whether there is also an official policy) that packages built with QEMU may not be uploaded to the archive.
KVM is also real hardware.
Yes, I'm aware of that. What I didn't know was whether QEMU or QEMU-KVM is being used on OBS.
Adrian
On Fri, Nov 24, 2017 at 5:28 AM, John Paul Adrian Glaubitz adrian.glaubitz@suse.com wrote:
On 11/24/2017 11:25 AM, John Paul Adrian Glaubitz wrote:> This could actually be true provided that OBS actually builds on QEMU and not
really iron. Looking at the build logs for mksh for ppc64 [1] and ppc64el [2] in Debian, I don't see this particular testsuite failure in any of the builds in the history.
Forgot to mention: Debian always uses real hardware for the build machines. The build maintainers and release managers have agreed (not sure whether there is also an official policy) that packages built with QEMU may not be uploaded to the archive.
For what it's worth, this has also been the policy in Fedora too. All architectures are built native, even if they're VMs on host hardware of the same architecture. We don't do emulated builds because they seem to produce weird output at times.
-
Adrian Schröter -
Andreas Schwab -
Dr. Werner Fink -
John Paul Adrian Glaubitz -
Neal Gompa