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

Reply via email to