You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We've got this test failure here on the Debian package. It appears randomly (however, oftenly), so it's hard to tell what triggers this, nor how to successfully reproduce it.
=================================== FAILURES ===================================
_______________ TestPopenGateway.test_waitclose_on_remote_killed _______________
self = <test_gateway.TestPopenGateway object at 0x7fbe7777a518>
makegateway = <bound method Group.makegateway of <Group ['gw0']>>
def test_waitclose_on_remote_killed(self, makegateway):
gw = makegateway('popen')
channel = gw.remote_exec("""
import os
import time
channel.send(os.getpid())
time.sleep(100)
""")
remotepid = channel.receive()
py.process.kill(remotepid)
py.test.raises(EOFError, "channel.waitclose(TESTTIMEOUT)")
> py.test.raises(IOError, channel.send, None)
E Failed: DID NOT RAISE <class 'OSError'>
testing/test_gateway.py:251: Failed
Anyway, any hint on this or a fix would be very welcome.
The corresponding bug report is https://bugs.debian.org/854494, please see there for moreinfo and buildlogs.
DS
Hello. This is happening again (or still happening).
On AWS instances of type m7a.medium and r7a.medium, building this package (version 2.1.1) on Debian unstable failed 100% of the time. I've put several build logs here for reference:
Activity
sanvila commentedon Jun 5, 2026
Hello. This is happening again (or still happening).
On AWS instances of type
m7a.mediumandr7a.medium, building this package (version 2.1.1) on Debian unstable failed 100% of the time. I've put several build logs here for reference:https://people.debian.org/~sanvila/build-logs/execnet/
After I marked the following tests as xfail, the problem seemed to be solved:
This would probably fall into this category which already exists:
@pytest.mark.xfail(reason="fails due to timing problems on busy single-core VMs")except that in this case the VMs do not really need to be "busy".
To reproduce, I recommend configuring GRUB with
GRUB_CMDLINE_LINUX="nr_cpus=1"and rebooting.Thanks.