Bugzilla – Bug 1225362
[SUSE:SLFO:Main] chrony fails to build on ppc64le and other non x86 architectures
Last modified: 2024-06-05 09:45:03 UTC
Hello, chrony currently fails to build for ppc64le (and other non x86 architectures). - https://build.suse.de/build/SUSE:SLFO:Main:Build/standard/ppc64le/chrony/_log - https://build.opensuse.org/package/show/network:time/chrony [ 413s] [ 413s] 124-tai Testing tai option: [ 413s] network with 0*1 servers and 1 clients: [ 413s] non-default settings: [ 413s] client_conf= refclock SHM 0 dpoll 0 poll 0 tai leapsectz right/UTC leapsecmode ignore maxchange 1e-3 1 0 [ 413s] limit=1200 [ 413s] max_sync_time=15 [ 413s] min_sync_time=2 [ 413s] refclock_jitter=1e-6 [ 413s] refclock_offset=(+ -34 (equal 0.1 (max (sum 1.0) 600) 600)) [ 413s] servers=0 [ 413s] starting node 1: OK [ 414s] running simulation: OK [ 414s] checking chronyd exit: [ 414s] node 1: BAD [ 414s] FAIL This is urgent since it is needed for upcoming SLE Micro 6.1 release, and affecting any other SLFO products.
Some of these tests seem to be timing sensitive and tend to fail on loaded machines. It usually helps to rebuild a few times to get a successful build.
(In reply to Reinhard Max from comment #1) > Some of these tests seem to be timing sensitive and tend to fail on loaded > machines. It usually helps to rebuild a few times to get a successful build. Is it possible to make chrony or the tests less timing sensitive? I'd expect that chrony also works if the system is under some load, which is especially likely during boot when chrony starts up. If not, a band aid could be to retry failing tests a few times until they pass...
Running each test multiple times and tolerating a certain amount of failures is already supported by the test suite, but not repeating a test until it succeeds or has exceeded a maximum amount of failures. Trying to add that...
Hmm, I tried running 124-tai 50 times on ppc64le and not a single one succeeded, so either this test fails for other reasons than timing sensitivity, or it is so sensitive that it never succeeds on slower machines.
It might be a floating point rounding issue that triggers the "Adjustment of %.3f seconds exceeds the allowed maximum of %.3f seconds (%s) " error message in reference.c, but I won't be able to continue debugging this before Wednesday.
I found a workaround by slightly modifying the configuration of the test. But given that I didn't fully understand the test I asked upstream what they think of it and will submit my workaround depending on their answer.
I meanwhile reported this upstream and quickly got an official fix: https://gitlab.com/chrony/chrony/-/issues/7 https://gitlab.com/chrony/chrony/-/commit/8f5b3084 A fixed package will soon get submitted to Factory. Please let me know where else I should submit it (if at all).
(In reply to Reinhard Max from comment #7) > I meanwhile reported this upstream and quickly got an official fix: > > https://gitlab.com/chrony/chrony/-/issues/7 > https://gitlab.com/chrony/chrony/-/commit/8f5b3084 > > A fixed package will soon get submitted to Factory. > Please let me know where else I should submit it (if at all). Please submit update to https://build.suse.de/project/show/SUSE:SLFO:Main Thanks for your support
SR#333097 This syncs the package with Factory, including an upgrade to version 4.5.
This is an autogenerated message for OBS integration: This bug (1225362) was mentioned in https://build.opensuse.org/request/show/1178691 Factory / chrony