http://bugzilla.opensuse.org/show_bug.cgi?id=1178453 http://bugzilla.opensuse.org/show_bug.cgi?id=1178453#c4 Axel Braun <axel.braun@gmx.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |IN_PROGRESS --- Comment #4 from Axel Braun <axel.braun@gmx.de> --- (In reply to Stefan Brüns from comment #3)

The gnuhealth-client is non-distributable, as it contains a binary blob, the camera plugin.

it comes with a __pycache__ which obviously caused the problem. I have removed it, rebuild and the client comes up normally. Thanks for the hint! -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1178453 http://bugzilla.opensuse.org/show_bug.cgi?id=1178453#c9 --- Comment #9 from Axel Braun <axel.braun@gmx.de> --- (In reply to Stefan Br�ns from comment #8)

This is more likely an issue of the openQA worker, openCV is doing runtime dispatching for CPU feature dependent code.

can you explain this in a way a 10yr old blonde understands it? ;-) Who needs to look into this? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1178453 http://bugzilla.opensuse.org/show_bug.cgi?id=1178453#c12 Axel Braun <axel.braun@gmx.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |axel.braun@gmx.de --- Comment #12 from Axel Braun <axel.braun@gmx.de> --- (In reply to Oliver Kurz from comment #11)

https://openqa.opensuse.org/tests/1476138#step/gnuhealth_client_first_time/1 is strange though. It was another retriggered test which ran with `QEMUCPU=qemu64` and it showed the client just fine *confused*

yes, and in current build 20201115 it runs fine as well. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1178453 http://bugzilla.opensuse.org/show_bug.cgi?id=1178453#c14 Axel Braun <axel.braun@gmx.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(stefan.bruens@rwt | |h-aachen.de) --- Comment #14 from Axel Braun <axel.braun@gmx.de> --- (In reply to Oliver Kurz from comment #13)

but that is with the workaround applied. I removed that again as Stephan Kulow suggested in https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/ 11414#issuecomment-728756213 to keep it failing to not hide the product issue that we can not easily work around.

axel.braun@gmx.de , assigning back to you as https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/ 11414#issuecomment-728717005 convinced me: If it doesn't run on certain cpus, it should be recompiled to do so.

Hm, there is basically nothing I can do from gnuhealth-side. And I cant judge if the openQA worker is the problem (maybe submitting invalid data?) or if opencv processes these data falsely. Or even a different problem. As we will probably release a new gnuhealth version soon (planned is this month) I would really like to get this fixed, or error removed by setting the host-CPU as suggested originally. What can we do? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1178453 Axel Braun <axel.braun@gmx.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|axel.braun@gmx.de |stefan.bruens@rwth-aachen.d | |e -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1178453 http://bugzilla.opensuse.org/show_bug.cgi?id=1178453#c19 Oliver Kurz <okurz@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(okurz@suse.com) | --- Comment #19 from Oliver Kurz <okurz@suse.com> --- (In reply to Stefan Br��ns from comment #17)

Sorry I haven't followed up on this.

I tried enabling the test suite in openCV, and the gapi test is also segfaulting on OBS. Unfortunately the test suite has to many external dependencies to be useful without much more work, so I have kept it disabled for now.

The gapi code seems to trigger some error probably related to qemu/kvm in its dispatch code (so either CPU dispatching chooses the wrong path, or the dispatched code is failing).

Will try to create trivial reproducer the coming days.

@dimstar, @fokurz - for runtime dispatched code it would be useful to have different (emulated) hardware, both on OBS (internal testsuite) and on openQA. Do we have something in place for this? I.e. request a host which has only SSE2.

Hm, I think what's possible is to run `osc build` locally or within respectively configured VMs. For openQA we can configure the VMs that are used for tests on the fly. E.g. with ``` openqa-clone-job --skip-chained-deps --within-instance https://openqa.opensuse.org 1583395 TEST=gnuhealth_only_sse2 QEMUCPU=base,sse2 _GROUP=0 BUILD=debug_bsc1178453 ``` I could create https://openqa.opensuse.org/t1583917 which (hopefully) will spawn a test job on a machine that has only sse2 enabled. We can tweak that with the "QEMUCPU" parameter which is directly passed to `qemu -cpu ���` Everyone with operator permissions on an openQA instance can run the same. You already have according permissions. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1178453 http://bugzilla.opensuse.org/show_bug.cgi?id=1178453#c23 --- Comment #23 from Stefan Br�ns <stefan.bruens@rwth-aachen.de> --- Even without LTO the code is malformed. Consider a C++ method which is marked as inline. Contrary to common belief this does not force the compiler to actually inline the code (although often it is true), but allows to have multiple definitions, all but one being discarded during link time. The C++ standard requires all these definitions to be identical sequences of tokens (which is trivially true for e.g. headers included in different source files). Given identical compiler options identical token sequences will result in identical machine code, so which of this definitions is chosen does not matter. Now with different architecture flags you will end up with some definitions which are heavily architecture dependent. The linker may or may not chose the one definition which crashes with an AVX-incapable machine. C++ inline methods are quite common, as each method defined in-class, and each template method are implicitly inline. There are two mechanisms which deals with this properly, either function-multiversioning (FMV), and the HWCAPS approach used by the very latest glibc. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1178453 http://bugzilla.opensuse.org/show_bug.cgi?id=1178453#c29 --- Comment #29 from OBSbugzilla Bot <bwiedemann+obsbugzillabot@suse.com> --- This is an autogenerated message for OBS integration: This bug (1178453) was mentioned in https://build.opensuse.org/request/show/1064690 Factory / gnuhealth-client -- You are receiving this mail because: You are on the CC list for the bug.