On Mon, 2023-02-06 at 21:39 +0000, Rebecca N. Palmer wrote: > I agree that xfailing the tests *may* be a reasonable solution. I'm > only saying that it should be done by someone with more idea than me > of > whether these particular tests are important, because blindly > xfailing > everything that fails is effectively not having tests. > > If we do choose that approach, at least test_balance_expensive_tasks > needs to be an outright xfail/skip not just a flaky, because when it > fails it fails repeatedly.
So my efforts at debugging are made harder by it working for me. I'm using a9771f68a28dfc65cae3ac6acf70451c264f3227 from Debian HEAD. = 2745 passed, 93 skipped, 216 deselected, 18 xfailed, 8 xpassed in 1992.20s (0:33:12) = I looked at the last log on ci.debian.org for dask.distributed https://ci.debian.net/data/autopkgtest/unstable/amd64/d/dask.distributed/31090863/log.gz And it looks like several of those errors are networking related. CI with the previously released 2022.12.1+ds.1-1 version is failing with these tests: test_defaults test_hostport test_file test_default_client_server_ipv6[tornado] test_default_client_server_ipv6[asyncio] test_tcp_client_server_ipv6[tornado] test_tcp_client_server_ipv6[asyncio] test_only_local_access test_remote_access test_adapt_then_manual test_local_tls[True] test_local_tls[False] test_run_spec test_balance_expensive_tasks[enough work to steal] I think several of those may depend on a proper network. The host I'm using actually has both ipv4 and ipv6 working. I'm using sbuild automatically running autopkgtests on a oldish 2x4 8 core xeon server with ~24 GB of ram What's your test environment like? I don't think head is hugely different from what was released in -1. The diff looks like Andreas adjusted the dask dependency version, configured a salsa CI run, and added some upstream metadata files He had problems with a salsa build failure but that was with i386, I'm currently setting up i386 to see if I can replicate the salsa failure. Diane