>
> That presumably means 5 days, which we don't have, i.e. *don't*
> unless
> release team tell you otherwise.
For what it's worth this is our answer from #debian-release
elbrus
detrout: I'll handle dask.distributed
detrout
elbrus, Thank you. sorry about needing to ask for an exception
>
> That might be true on amd64, but I don't think it's true of
> arm*/s390x:
> the tests that are failing there do *not* appear to be isinstalled
> tests.
>
> I suspect the tests wouldn't have worked on those architectures in
> 2022.02 either, and we didn't notice because the previously
On 10 February 2023 1:28:04 pm IST, "Rebecca N. Palmer"
wrote:
>On 10/02/2023 06:41, Andreas Tille wrote:
>> Am Fri, Feb 10, 2023 at 08:44:01AM +0530 schrieb Nilesh Patra:
>>> But I am not sure if this counter would be set to 2 days (from 5 days)
>>> or not -- will likely need to ask release
On 10/02/2023 06:41, Andreas Tille wrote:
Am Fri, Feb 10, 2023 at 08:44:01AM +0530 schrieb Nilesh Patra:
But I am not sure if this counter would be set to 2 days (from 5 days)
or not -- will likely need to ask release team.
As far as I observed the migration time is now 5 days (no matter
Hi,
Am Fri, Feb 10, 2023 at 08:44:01AM +0530 schrieb Nilesh Patra:
> Some tests passed after I put it for (multiple) retries. The
> current state looks fine
>
> https://qa.debian.org/excuses.php?package=dask.distributed
Thanks to you all three for your work.
> But I am not sure if this
On Fri, 2023-02-10 at 08:44 +0530, Nilesh Patra wrote:
> Control: fixed -1 2022.12.1+ds.1-2
>
> Some tests passed after I put it for (multiple) retries. The
> current state looks fine
>
> https://qa.debian.org/excuses.php?package=dask.distributed
>
> But I am not sure if this counter
Control: fixed -1 2022.12.1+ds.1-2
Some tests passed after I put it for (multiple) retries. The
current state looks fine
https://qa.debian.org/excuses.php?package=dask.distributed
But I am not sure if this counter would be set to 2 days (from 5 days)
or not -- will likely need to ask
Upstream's reason for treating warnings as errors is just generic 'find
potential problems' (https://github.com/dask/distributed/issues/6048).
On 09/02/2023 21:33, Diane Trout wrote:
That worked, but armel (test_steal_twice), armhf (something outright
crashing) and s390x (lots) all failed.
On 09/02/2023 21:33, Diane Trout wrote:
The place to ask is debian-release; no comment on the likely result.
I'll try to ask.
Looking at the old logs, I think the old "passing" test *didn't actually
run* the tests (just collected them, which was enough to fail on a
dask/dask.distributed
On Thu, 2023-02-09 at 21:21 +, Rebecca N. Palmer wrote:
>
>
> On 09/02/2023 17:07, Diane Trout wrote:
> > Would it make sense to drop those errors back to warnings, and do
> > you
> > know enough about the setup.cfg language to do it quickly?
> >
>
> Plausibly yes but I don't actually
On 09/02/2023 17:07, Diane Trout wrote:
Would it make sense to drop those errors back to warnings, and do you
know enough about the setup.cfg language to do it quickly?
Plausibly yes but I don't actually know, and remove the 'error' line at
setup.cfg:60.
I went ahead and requested
On Thu, 2023-02-09 at 07:44 +, Rebecca N. Palmer wrote:
> On 09/02/2023 06:36, Diane Trout wrote:
> > Also there's still some flaky tests as the rebuild triggered by my
> > just
> > committing the changelog release had a failure in
> > "test_release_retry"
>
> I don't think I've seen that
On 09/02/2023 06:36, Diane Trout wrote:
Also there's still some flaky tests as the rebuild triggered by my just
committing the changelog release had a failure in "test_release_retry"
I don't think I've seen that particular one before, though like several
others it's a warning being treated as
On Wed, 2023-02-08 at 23:11 +, Rebecca N. Palmer wrote:
>
> Mostly, please upload *something* today, because we won't know for
> sure
> whether it passes on a real buildd/debci until we try that, and if it
> doesn't then the sooner we find out the better.
>
It's uploaded it earlier today
Am Wed, Feb 08, 2023 at 11:11:49PM + schrieb Rebecca N. Palmer:
> Mostly, please upload *something* today, because we won't know for sure
> whether it passes on a real buildd/debci until we try that, and if it
> doesn't then the sooner we find out the better.
+1
Thanks to you both for all
On 08/02/2023 22:09, Diane Trout wrote:
I just got back a passed from salsa. So does anyone want to make any
more changes? Or should we release this version?
The *maybe* remaining issue is that test_balance_expensive_tasks[enough
work to steal] seems to fail repeatedly when it fails, so if we
Hello,
So I discovered I'd forgotten to do git cherry-pick --continue so
missed the last patch from Rebecca. (b82894aa) Thank you so much for
working out a better strategy for the flaky tests.
I also found a computer I could log into that has has no working ipv6
support, and so could more
I think I got the code to detect if IPv6 is available to work correctly
so I could set the DISABLE_IPV6 environment variable that
dask.distrubted supports.
This probably refers to
https://salsa.debian.org/python-team/packages/dask.distributed/-/blob/debian/master/debian/tests/run-tests#L11
18 matches
Mail list logo
