Hi, Debian and Ubuntu run the self tests of snek as integration tests like:
`make SNEK_NATIVE=/usr/bin/snek SNEK_ARM=/usr/share/snek/snek-arm SNEK_RISCV=/usr/share/snek/snek-riscv -C test check` Those tests recently generated signal by failing in the arm emulation tests with `qemu-system-arm` - full log [1]. ``` 224s Running test pass-precedence.py. 224s pass python3 224s pass snek 224s pass-precedence.py:72 Syntax error at "". 224s ***************** snek-arm fail ********************* 224s pass snek-riscv ``` 14 tests failed, but all with quite similar signatures. But that only happens when executed on armhf, the other host architectures are all happy [2]. I've separated the test and ran a git bisect on qemu 10.0 -> 10.1 as somewhere here is the trigger. That worked fine and identified this change [3]. I must admit, I was able to debug it until here, but I can't see how these snek test failures could be caused by that change. And yes - arm emulation on an armhf platform isn't the most common scenario. I can't predict if there is anything wrong in snek which now is treated differently by qemu to trigger this or if snek is all fine and qemu broken something - Therefore I've also reported it to snek [4]. The tracking of the initial finding in Ubuntu is here if you want to see more about how this commit was identified [5]. [1]: https://autopkgtest.ubuntu.com/results/autopkgtest-questing/questing/armhf/s/snek/20250818_045020_246a4@/log.gz [2]: https://autopkgtest.ubuntu.com/packages/s/snek [3]: https://salsa.debian.org/qemu-team/qemu/-/commit/cf4905c03135f1181e86c618426f8d6c703b38c0 [4]: https://github.com/keith-packard/snek/issues/103 [5]: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/2121124 -- Christian Ehrhardt Director of Engineering, Ubuntu Server Canonical Ltd