[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Migration-preventing autopkgtest failures

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.


Reply to: