Documentation says the threshold is 150MB, but the actual value was 200MB. Fixing this with a correct value, documentation (and previous commit message) are right here.
Thanks to vkadlcik@redhat.com for spotting the issue.
The library size can vary a bit, 100MB is sort of correct, but e.g. RHSCL version is 106MB. Bumping the size threshold to 150MB, it should b still safely within the original bug report of 2GB.
lld and libomp are not shipped in s390x, hence causing provisioning
prepare step to fail as they are required in llvm-integration-testsuite.
The test should still run fine without those packages.
I noticed that warnings and errors show up in the `RPM build errors:`
output. When I produced an error I did see this warning about absolute
symlink showing up:
```
absolute symlink: /usr/lib64/bfd-plugins/LLVMgold.so -> /usr/lib64/LLVMgold.so
```
The upstream RPM fix to log warnings and errors separately is here:
https://github.com/rpm-software-management/rpm/pull/1590
Thanks to @sergesanspaille for the help.
On ARM, the default linker is lld when using the clange toolchain,
so specify that as the _package_note_linker. This will use the
-T rather than -dT option for the package note script.
Ideally this would be handled in a more central location.
My expectation is that in the future, more tests will land in this git,
and not all of them would be useful in gating time. AFAIK, CI systems do
run everything they can, therefore adding `when` to control when the
plan is executed - `is not defined` bit should allow anyone to run it
manually, while the rest of the condition should limit its presence to
gating events.
This was originally stored in provision.fmf, but after the TMT
transition, this information should be preserved. It is probably not
honoured by that many CI systems, but things will get better over time.
See https://tmt.readthedocs.io/en/stable/spec/plans.html#hardware for
specification details.
* tests.yml => tests-llvm.yml, to allow composition by "dumping" tests
from several LLVM components when testing a module or collection;
* more comments, to highlight part where downstream maintaners and QEs
need to modify tests;
* fixed failing tests to get a clean table as a verification tests do
work after my changes.
