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
