15942 2025-07-25 08:23:06 +0000 AB-INT PTEST RISCV64: python3-hypothesis ptest failure 2026-06-11 15:04:15 +0000 1 1 10 QA/Testing Package Testing (ptest) ptest unspecified RISCV Multiple RESOLVED WORKSFORME AB-INT Medium normal 6.1 1 joaomarcos.costa unassigned mathieu.dubois-briand randy.macleod richard.purdie tgamblin --- --- Don't know oldest_to_newest 102512 0 joaomarcos.costa 2025-07-25 08:23:06 +0000 https://autobuilder.yoctoproject.org/valkyrie/#/builders/56/builds/242/steps/12/logs/stdio Failed ptests: {'python3-hypothesis': ['examples/test_binary_search.py:test_insert_is_sorted']} qemuriscv64-ptest stream9-vk-1 There was a recent update to v6.135.29, which could explain this issue: From OE-Core rev: fa2cdb90fc6e28532b0b368a0aa4c00748e19061 ---- START: ptest-runner 2025-07-23T17:15 @given(ls=SortedLists, v=Values) > def test_insert_is_sorted(ls, v): ^^^ E hypothesis.errors.FailedHealthCheck: Data generation is extremely slow: Only produced 6 valid examples in 1.77 seconds (0 invalid ones and 1 exceeded maximum size). Try decreasing size of the data you're generating (with e.g. max_size or max_leaves parameters). E count | fraction | slowest draws (seconds) E ls | 7 | 99% | 0.006, 0.007, 0.008, 0.018, 1.706 E v | 6 | 1% | 0.002, 0.002, 0.003, 0.003, 0.005 E See https://hypothesis.readthedocs.io/en/latest/reference/api.html#hypothesis.HealthCheck for more information about this. If you want to disable just this health check, add HealthCheck.too_slow to the suppress_health_check settings for this test. examples/test_binary_search.py:100: FailedHealthCheck FAIL: examples/test_binary_search.py:test_insert_is_sorted PASS: examples/test_binary_search.py:test_is_minimal PASS: examples/test_binary_search.py:test_inserts_into_same_place_twice PASS: examples/test_rle.py:test_decodes_to_starting_sequence PASS: examples/test_rle.py:test_duplicating_an_element_does_not_increase_length ============================================================================ Testsuite summary # TOTAL: 5 # PASS: 4 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 ERROR: Exit status is 1 DURATION: 64 102532 1 richard.purdie 2025-07-31 14:37:41 +0000 Looks like it is slow so we may want to tweak the timeout? 104500 2 randy.macleod 2026-03-04 23:06:28 +0000 Only seen once in July 2025 - resolve? 104511 3 tgamblin 2026-03-05 13:42:38 +0000 I am conflicted. On one hand, if it hasn't been seen for months it's probably OK to close, but it's starting to look like this is an underlying performance issue somewhere in the kernel/QEMU/toolchain optimization triangle, so I doubt it's actually gone away unless something drastic has changed in the upstream package. 105602 4 randy.macleod 2026-05-28 13:16:29 +0000 Bulk move of 6.0 Medium bugs to 6.1. 105837 5 randy.macleod 2026-06-11 15:04:15 +0000 Single event. Not seen in > 6 months.