Hi, I happen to use 'ninja -C build test to do a (usually) quick sanity test on patches and changes and whatnot. An usual run of this target tests around 327 individual tests with the RISC-V stuff I usually build.
After pulling today's master 'ninja -C build test' is now running a whooping 1366 tests. Here's an example: $ ninja -C build -j 9 test ninja: Entering directory `build' mkvenv: checking for pygdbmi>=0.11.0.0 mkvenv: installing pygdbmi==0.11.0.0 [2/3] Running all tests [1-12/1366] (....) (....) [250-260/1366] 🌕 block-qcow2-optional+block-slow - qemu:io-qcow2-014 [250-261/1366] 🌖 block-qcow2-optional+block-slow - qemu:io-qcow2-014 [252-262/1366] 🌒 block-qcow2-optional+block-slow - qemu:io-qcow2-026 (...) I noticed a lot of these "optional+block-slow" tests being ran now, something that wasn't happening before. If I use 'make check' I have the results I was having with 'ninja -C build test' before the recent changes. I tried to bisect and got to this commit: commit daf0d008822be3cb14cdb533f7237c3c789bc373 (HEAD) Author: Daniel P. Berrangé <[email protected]> Date: Mon Jan 12 13:01:49 2026 +0000 iotests: remove redundant meson suite for iotests From what I can tell this commit triggered (unintended?) stuff that was already in the code. In other words I am not sure if this commit is actually the culprit, so I am reluctant to even call this a bug. My question is: should I be using 'ninja test'? It seems to me that the common practice is to use 'make check' and maybe I've been using an "unsupported" testing scheme. Cheers, Daniel
