Source: matrix-synapse Version: 1.128.0-1 Severity: serious Tags: FTBFS, patch User: debian-ri...@lists.debian.org Usertags: riscv64
Dear matrix-synapse maintainer,
The package matrix-synapse build failed on riscv64.The crucial buildd log
below:
```
=================================== FAILURES ===================================
___________________ WorkerLockTestCase.test_lock_contention ____________________
self = <tests.handlers.test_worker_lock.WorkerLockTestCase
testMethod=test_lock_contention>
def test_lock_contention(self) -> None:
"""Test lock contention when a lot of locks wait on a single worker"""
# It takes around 0.5s on a 5+ years old laptop
with test_timeout(5):
nb_locks = 500
d = self._take_locks(nb_locks)
> self.assertEqual(self.get_success(d), nb_locks)
/build/reproducible-path/matrix-synapse-1.128.0/.pybuild/cpython3_3.13_matrix-synapse/build/tests/handlers/test_worker_lock.py:61:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
/build/reproducible-path/matrix-synapse-1.128.0/.pybuild/cpython3_3.13_matrix-synapse/build/tests/unittest.py:692:
in get_success
self.pump(by=by)
/build/reproducible-path/matrix-synapse-1.128.0/.pybuild/cpython3_3.13_matrix-synapse/build/tests/unittest.py:688:
in pump
self.reactor.pump([by] * 100)
/usr/lib/python3/dist-packages/twisted/internet/task.py:838: in pump
self.advance(amount)
/build/reproducible-path/matrix-synapse-1.128.0/.pybuild/cpython3_3.13_matrix-synapse/build/tests/server.py:642:
in advance
super().advance(0)
/usr/lib/python3/dist-packages/twisted/internet/task.py:830: in advance
call.func(*call.args, **call.kw)
/build/reproducible-path/matrix-synapse-1.128.0/.pybuild/cpython3_3.13_matrix-synapse/build/synapse/util/__init__.py:201:
in wrapped_callback
callback(*args, **kwargs)
/build/reproducible-path/matrix-synapse-1.128.0/.pybuild/cpython3_3.13_matrix-synapse/build/synapse/handlers/worker_lock.py:191:
in _wake_all_locks
if not deferred.called:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self = <tests.utils.test_timeout object at 0x3f9e3e74d0>, signum = 14
frame = <frame at 0x3f9bda9560, file
'/build/reproducible-path/matrix-synapse-1.128.0/.pybuild/cpython3_3.13_matrix-synapse/build/synapse/handlers/worker_lock.py',
line 191, code _wake_all_locks>
def handle_timeout(self, signum: int, frame: Optional[FrameType]) -> None:
> raise TestTimeout(self.error_message)
E tests.utils.TestTimeout: Test timed out after 5s
/build/reproducible-path/matrix-synapse-1.128.0/.pybuild/cpython3_3.13_matrix-synapse/build/tests/utils.py:424:
TestTimeout
```
The full buildd log is here:
https://buildd.debian.org/status/fetch.php?pkg=matrix-synapse&arch=riscv64&ver=1.128.0-1&stamp=1746950558&raw=0
My solution to this issue:
The `test_lock_contention` test, which simulates high lock contention, is
timing out on RISC-V systems likely due to inherent performance differences
of the architecture compared to more established platforms like x86_64, for
which the current 5-second timeout is calibrated.
To address this without masking potential regressions on other
architectures, I propose to conditionally adjust the timeout duration for
the RISC-V architecture. This is achieved by detecting the architecture
using `platform.machine()` within the test case and applying a more lenient
timeout (e.g., 15 seconds) specifically for RISC-V.The debdiff patch is in
the attachment.I have tested that locally,and it works well.Please let me
know whether this solution can be accepted.
Gui-Yue
Best Regards
fix_matrix-synapse_test_timeout_on_riscv.patch
Description: Binary data
