Repository navigation
test_schedule_many_distinct_shapes_stays_bounded fails on Arch Linux #1152
Description
Hi, I'm building a package for Arch Linux from release 0.27.0, but one of the tests always fails:
test internal::tests::test_scheduler_sn::test_schedule_many_distinct_shapes_stays_bounded ... FAILED
failures:
---- internal::tests::test_scheduler_sn::test_schedule_many_distinct_shapes_stays_bounded stdout ----
[2026-10-25T10:25:44Z ERROR tako::internal::scheduler::main] Scheduler made no progress within given time limit
thread 'internal::tests::test_scheduler_sn::test_schedule_many_distinct_shapes_stays_bounded' (22683) panicked at crates/tako/src/internal/tests/test_scheduler_sn.rs:1694:5:
assertion failed: start.elapsed() < Duration::from_secs(10)
failures:
internal::tests::test_scheduler_sn::test_schedule_many_distinct_shapes_stays_bounded
test result: FAILED. 265 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 10.19s
error: test failed, to rerun pass `-p tako --lib`
Our build server has AMD EPYC 9454P 48-Core Processor and the build steps are recorded here. Any idea what is wrong?
Activity
spirali commentedon Oct 27, 2026
It seems as a problem with microlp. I will try to investigate more at the end of the week.
spirali commentedon Oct 30, 2026
The problem is that microlp is not able to find any feasible solution even in the fallback (simplified) formulation which I did not expect that can happend. I will fix it with a second level fallback that will not use MILP solver.
Btw: Would it be possible to use HiGHs solver in the Arch? Previously, the solver was used only in solving NUMA allocations, so it was not that critical but recent versions use MILP solver in the server so using microlp could be damaging for much larger usecases.
lahwaacz commentedon Nov 1, 2026
We had a problem with highs on Arch Linux previously: #1066
I think the state of things did not change much since that time, so I think compatibility-wise it would be better to rely on milp.
spirali commentedon Nov 2, 2026
In PR #1160 is flag "highs-system" that tries to link existing highs, so it do not have to be built. Maybe it help with problems on Arch.
I am also attaching the alternative option found by Claude, which I did not tested:
Cause:
makepkgadds-flto=auto, but the PKGBUILD adds-ffat-lto-objectsonly toCFLAGS. HiGHS is C++, so it is built fromCXXFLAGSandlibhighs.aends up with almost only GCC LTO bytecode. The Rust link cannot use that, so theHighs_*symbols stay undefined. Switching fromlldto GNUldgives the same error.Fix: add the flag to
CXXFLAGSas well: