Description
We use packit-service for some CI build tests in util-linux where we run a large stack of regression tests before the build. Some of these regression tests make assumptions about the platform that can cause failures which we would like to avoid proactively.
One such example is a test for the kill(1) command which will send signals with every signal number assumed to be supported on the running system. This test, unfortunately, fails in higher value ranges for real-time signals (SIGRTMAX) on QEMU emulated systems, as the conversion done by the QEMU internals restricts the available range.
To avoid this we could simply check whether the container instance PID 1 is mapped to a qemu- emulator (binfmt_misc) and then skip the test. However, as we are not running as root this is certainly not possible, so we may need some help from the host.
The idea is to pass a set of environment variables to the container that can inform about the platform's specifics or other useful information, e.g. QEMU_USER=1. And then help to take well-informed decisions in our test scripts.
Benefit
Projects that want to improve their multi-arch test suites' adaptability and robustness would benefit a lot from the provided information by the host.
Importance
It is not necessarily blocking, but it creates a bit of noise that could be avoided with assumedly little effort on this end.
What is the impacted category (job)?
Copr builds
Workaround
Participation
Description
We use packit-service for some CI build tests in util-linux where we run a large stack of regression tests before the build. Some of these regression tests make assumptions about the platform that can cause failures which we would like to avoid proactively.
One such example is a test for the kill(1) command which will send signals with every signal number assumed to be supported on the running system. This test, unfortunately, fails in higher value ranges for real-time signals (SIGRTMAX) on QEMU emulated systems, as the conversion done by the QEMU internals restricts the available range.
To avoid this we could simply check whether the container instance PID 1 is mapped to a qemu- emulator (binfmt_misc) and then skip the test. However, as we are not running as root this is certainly not possible, so we may need some help from the host.
The idea is to pass a set of environment variables to the container that can inform about the platform's specifics or other useful information, e.g.
QEMU_USER=1. And then help to take well-informed decisions in our test scripts.Benefit
Projects that want to improve their multi-arch test suites' adaptability and robustness would benefit a lot from the provided information by the host.
Importance
It is not necessarily blocking, but it creates a bit of noise that could be avoided with assumedly little effort on this end.
What is the impacted category (job)?
Copr builds
Workaround
Participation