Hi Christian, On 04-04-2020 23:42, Christian Kastner wrote: > Can and will do so with a patch (as I'm already handled the very same > issue with src:scikit-learn). However, I have two questions before I do so: > > * Severity is "wishlist", right? The autopkgtest docs say "In general, > tests are also allowed to access the internet".
This used to be true until we got Chinese workers. Unfortunately China has restrictions on internet use, so that documentation is outdated. We will probably move soon to a situation where tests have to declare the need for unrestricted internet access in their restrictions and we will not run those on arm64. Apart from this issue, it is good for QA to know exactly which packages need unrestricted internet access, as it enables us to inspect the use of the internet in autopkgtest. Recently the ftp-masters discovered a class of usage that they don't allow. All in all, I think normal or important is most suited at this moment until we have a general solution (see below). > * It's sufficient to exclude these tests on arm64 (where they are > currently failing, right? I am reluctant to say yes. The point is that on amd64 we can still support this (but at one moment may not) and it's not pretty that packages individually have to start implementing checks and updating architectures where this is or isn't possible. This should be done at the global level. Hence, my proposal to use restrictions. > Or is it better to this be done generally? I'd say, with the absence of support of the needs-internet restriction (coming soon hopefully) it's best (if easily achievable) to check if internet access is possible and skip the test if it's not. On top of that, test that need internet resources should always account for some temporary outage and retry after some seconds waiting. And, how stable is the resource you need? We don't want tests (especially not in stable and oldstable) that start failing just because some web-site operator outside of our control changed the content that a test needs. > A third question, independent of the bug: why do I see the failing test > in src:scikit-learn's tracker, but not in src:dask's, or dask's CI page? > > https://ci.debian.net/packages/d/dask/ We also have workers outside of China, so the result depends on which worker the test ran. Paul
