Re: Migration-preventing autopkgtest failures

[Christian Kastner <ckk@debian.org>]

Hi Paul,

thanks for the quick reply.

On 2020-04-04 21:26, Paul Gevers wrote:
> Hi Christian.
> 
> If you don't mind, please reply to this e-mail with
> debian-release@lists.debian.org in TO. There is nothing private in this
> e-mail.
> 
> On 04-04-2020 11:32, Christian Kastner wrote:
>> I looked at the logs, and src:dask fails because of network access, and
> 
> This is indeed something that can happen on the Chinese arm64 workers of
> ci.debian.net, similar to bug #955535. On IRC (#debci) we have started
> the discussion how to proceed with this. I think we will be coming up
> with a new restriction: needs-internet or something. In the mean time,
> this warrants a bug and an ignore hint. Do you care to file the bug report?

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".

  * It's sufficient to exclude these tests on arm64 (where they are
    currently failing, right? Or is it better to this be done generally?

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/

>> src:dask.distributed fails because of some distributed running timing issue.
> 
> That test looks flaky, I'll file an RC bug and add an ignore hint.
> 
>> What's the process of getting these issues resolved? Is there a process
>> to whitelist these issues for the affected reverse-dependencies?
> 
> Yes, file a bug against release.debian.org explaining the situation and
> the release team can add hints to the configuration of the migration
> software (britney).

Great, will do so next time.

Thanks again!

Christian