Hi Diane, Hi Julian

I'm wrapping up that email as it seems to me there could be some
activity on the dask package from several people at once.

I happen to have a look at the dask.dataframe import issues,
which manifest as at least #1068422, #1069821, and #1069359.
The import problem looks fixed in 2024.5.2, but the new version
also introduced a couple of issues:

* the following change[1] is needed to fix a test failure[2].

[1]: https://github.com/dask/dask/pull/11177
[2]: https://github.com/dask/dask/issues/11176

* dask.distributed failed its supposedly flaky autopkgtest
with an error which suggests the two packages might have to
be uploaded in a lockstep:

____________ ERROR collecting protocol/tests/test_highlevelgraph.py ____________
/usr/lib/python3/dist-packages/dask/dataframe/__init__.py:22: in _dask_expr_enabled
import dask_expr # noqa: F401
E ModuleNotFoundError: No module named 'dask_expr'

Besides, dask.distributed build time tests also regress the
same way.

* napari is failing to build from source, but I haven't
checked yet whether this was caused by introduction of the
new dask or something else.

Otherwise, according to my tests on reverse dependencies and
reverse build-dependencies on amd64, the new dask did not
introduce regressions. The majority of packages saw their tests
and builds pass, and the rest had existing failures already.

If that helps, I have the package upgrade staging on my drive,
and may push to salsa after a good night of sleep. In case you
see reasons I missed for not bumping version too soon, or if you
already went through the upgrade steps already, don't hesitate
to tell me to hold my horses.

I did not focus a lot on the sphinxdoc issue described in the
newly opened #1073183. I'm not very good with dealing with
sphinxdoc, and would be more tempted to copy the bare rst files
than getting the html files back on tracks.

Have a nice day, :)
--
.''`. Étienne Mollier <emollier@debian.org>
: :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da
`. `' sent from /dev/pts/1, please excuse my verbosity
`- on air: Suspyre - Siren (One Last Breath)

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEj5GyJ8fW8rGUjII2eTz2fo8NEdoFAmZsszcACgkQeTz2fo8N Edqz4Q//aEtSH7uOIctJFgASFs2eY3DB6oR4oW1azIZLZ8QdKdPTjt/N8ZEbVJCV DtFJfwMSck9uq+2K6vD74wQC4T2pxjC/PRlI2wl0lj7ls07lFs8FOUI6lbWP+dvU es98rF2mKl6ep0ZfNarzZQIeSuCo0CZow0CYEN6VYZv95t1ADM5wIz52IwHzeG/p 4JM5eeirX/7Ece5DUAutDGfgAjkD7qB3/dv8ROpUQyMCr5GzSWpN+OWo8D79QZMi fALD27n0iBgbxEwkLhWKU1GNJefNTcJR1SrrgNHJjLPfWtY/spqfh9PePWG3L/q/ 4HoWn0+3GTRhvMFEcgQH810Wxp+eUrYFXRmlzBu3GntChV15hskqdioacTJTDuuF pyBlZt9B+14dDFzYbZ2ohgKOq13HndeIUSHnNtYQ2+QyUnlEKIGQgOoJVndS1TDv 4FMEziYn1hOkg18E6k0PdaxJSlGjwAgieV8MCxWuwI/PNuYUIxd2FqPDSlPk8afh Wo5ywNmiJkDcasixEfTc+WGpp8BxWPrY2yBmQmNk2e9jg+vfTGq78WgJ+CJNxK3Z ddjyUYzL+GFZd890PbrS4Ld6xVkFFeD29e0kQ4qOpibv1LcG2aEt2FR5SLXVFInT IQXkZZTQecNd8eZD1dI5AmB1zCbeTRFg

On Fri, 2024-06-14 at 23:16 +0200, Étienne Mollier wrote:

Hi Diane, Hi Julian

I'm wrapping up that email as it seems to me there could be some
activity on the dask package from several people at once.

Yeah I saw that and decided I was overloaded and stopped doing
anything.

Historically it was pretty important to dask and dask.distributed to be released together, upstream intends them to be matching versions, but I
didn't know how to set the the dependnecy version strings to require
that.

I happen to have a look at the dask.dataframe import issues,
which manifest as at least #1068422, #1069821, and #1069359.
The import problem looks fixed in 2024.5.2, but the new version
also introduced a couple of issues:

  * the following change[1] is needed to fix a test failure[2].

    [1]: https://github.com/dask/dask/pull/11177
    [2]: https://github.com/dask/dask/issues/11176

  * dask.distributed failed its supposedly flaky autopkgtest
    with an error which suggests the two packages might have to
    be uploaded in a lockstep:

Yes very much yes. Is there a way to nag anyone trying to upload dask
to go check the harder to update distributed before uploading?

If that helps, I have the package upgrade staging on my drive,
and may push to salsa after a good night of sleep.  In case you
see reasons I missed for not bumping version too soon, or if you
already went through the upgrade steps already, don't hesitate
to tell me to hold my horses.

That all seems promising to me.

I did not focus a lot on the sphinxdoc issue described in the
newly opened #1073183.  I'm not very good with dealing with
sphinxdoc, and would be more tempted to copy the bare rst files
than getting the html files back on tracks.

If you want to push what you've done I might have time sunday night/
monday to look at the sphinx problem.

Dask is probably complicated enough to be a good candidate for team maintenance.

Diane

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEETQVcMeSBIEX5AQ11mQ04NnM013AFAmZs92YACgkQmQ04NnM0 13D+IxAAgZ+gSn7KnXsdW1/LrQPF8SUQr8T3Zm6UoYnz4aLShdiOPe2FDDlBYHVn wZmCbrVbbgFyrSsiFeGWHnFL89u894YSDOXwaA1qv551gHbCdwxJu9QcEhG9bC/w n7HD9uiWOOCC3qlgsy6OqOH/Ffhs5ZEKq/XF60cNVJ1B8bZFBFQDKi8PKpg5Kav1 P9CB5UVxdjxweC4oF8svmKbZIRjQm72CFE+uMTZTlRJVw9vRs8ENMTk4HNhG3sjH BVzN9sEymPOkIJ6lYBsnbds2GM+w8nsqnhx6ErYg9DNEcR3EGcp/50Oidl5JgvGw sLsyk3ykvGAOFczPOt4tNS/afw87lWV/UEvdE3rGWklq+MdNEoPoY906xn3heA3e NafKTqOJjx4Vdmq3AHDFyLWQ6ZVYbO5uj8Tj2KSLTddu5Oh/ebhz/Wdg4zk58lHY nhxDjIGHNnJHQn1BdrylD5NRfA5obzb5QHw8jbyxwddz1kvozEJaUcW0bMImz862 SzHCqb3I3LYlBDC8ykhbYTbTW5yPDz4xWgW23FzrETXFqyBAN2ZU0VMI7ki8pyO5 K6zJ+KI5iRqY5DrhgehBAM4eDXV2oqTREDuMo0913R6paJMguC1deymPVJ7blaf9 OlXHlbqO4Qf6cgzdehKLU1ybvmbRJCTHiDLS/3SSSLolw8tWwtw=
=myey
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Diane,

Diane Trout, on 2024-06-14:

On Fri, 2024-06-14 at 23:16 +0200, Étienne Mollier wrote:

Hi Diane, Hi Julian

I'm wrapping up that email as it seems to me there could be some
activity on the dask package from several people at once.

Yeah I saw that and decided I was overloaded and stopped doing
anything.

Historically it was pretty important to dask and dask.distributed to be released together, upstream intends them to be matching versions, but I didn't know how to set the the dependnecy version strings to require
that.

It makes sense. The construction pretty much looks like the
latter is supposed to be a Python submodule of the former.

I happen to have a look at the dask.dataframe import issues,
which manifest as at least #1068422, #1069821, and #1069359.
The import problem looks fixed in 2024.5.2, but the new version
also introduced a couple of issues:

  * the following change[1] is needed to fix a test failure[2].

    [1]: https://github.com/dask/dask/pull/11177
    [2]: https://github.com/dask/dask/issues/11176

  * dask.distributed failed its supposedly flaky autopkgtest
    with an error which suggests the two packages might have to
    be uploaded in a lockstep:

Yes very much yes. Is there a way to nag anyone trying to upload dask
to go check the harder to update distributed before uploading?

A mention about the interdependency in d/README.source may help,
but getting dask.distributed autopkgtest to not be flaky anymore
would prevent migration of a mismatched distribution to testing,
and raise some alarms in the maneuver; that is, assuming version
mismatch is going to cause test failures in dask.distributed in
every cases.

If that helps, I have the package upgrade staging on my drive,
and may push to salsa after a good night of sleep.  In case you
see reasons I missed for not bumping version too soon, or if you
already went through the upgrade steps already, don't hesitate
to tell me to hold my horses.

That all seems promising to me.

I did not focus a lot on the sphinxdoc issue described in the
newly opened #1073183.  I'm not very good with dealing with
sphinxdoc, and would be more tempted to copy the bare rst files
than getting the html files back on tracks.

If you want to push what you've done I might have time sunday night/
monday to look at the sphinx problem.

Okay, I pushed my work in progress on Salsa, so anyone can build
on top of it. In the meantime I can change target and see to
move dask.distributed forward.

Dask is probably complicated enough to be a good candidate for team maintenance.

Diane

Thank you for your time putting the additional context!

Have a nice day, :)
--
.''`. Étienne Mollier <emollier@debian.org>
: :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da
`. `' sent from /dev/pts/3, please excuse my verbosity
`-

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEj5GyJ8fW8rGUjII2eTz2fo8NEdoFAmZtVckACgkQeTz2fo8N Edop1w/+KovJSNvmj4IYBD1Ap7W7k7LYzJTsbgiI7DVeXRXdK9L6C/T27+s3lrXV y5VEkj8NttkLpje8riHO9c7b+pdeFwYb6kFbgVjaXdieruZ4pKtUDwftkINfocww UzUbAbhMmCeubpzO3Ub+SyEh3WIMtW7VBQssW81g9ApxDE9KEQ89Z1HCG05SRxEW MdANN/jFEEh1y8i7gRW84myqwScVQ57HqhJ4XqJuQbagDodBS7xfdsx6QRXQMvEM bosXyVFNKfuk16GVizZ988HS67X2g2UGpHVmOR4fdolOpV1ho0x9YFQ3xbSv2gJY dx48bu/6cEOUSXwwyXuDNenY4SfEr9gRgrkeMzAJsWdqaCuXNyZpVv9YIH0W9OKi 9K38aIROROKqlwYyHyW0bMJXqJGkpn5eNRvCYSljN0y4FtfdMamfs3qK7VgF7xKk SQ5vx2mTlf98rME+dOjZqa8yFTMzIWz8D4edk/rfaTWzikFlxsL6QkjeQH5imGgU aJd7fEZ8iR5i1EeKd8elJ/pg2at/mqrgiHoKte6yH/WyX6nZ7Pf7P2+1OP8Rgex6 xuAddLVLk0JhPQSuMbMBklQC8S5WX/21vCMOWzDNgOpMn6xwq6O4ydgc9tJFsSWa XCxkjD8SaO+5E1Uetpo+gnI+g9K4+g3n/TlV+rzCJrMuCa+Sfng=
=YyQW
-----END PGP SIG

On Sat, Jun 15, 2024 at 10:50:17AM +0200, Étienne Mollier wrote:

Historically it was pretty important to dask and dask.distributed to be released together, upstream intends them to be matching versions, but I didn't know how to set the the dependnecy version strings to require
that.

It makes sense. The construction pretty much looks like the
latter is supposed to be a Python submodule of the former.

You could do something like this in the dask.distributed source
package:

Source: dask.distributed
Build-Depends: python3-dask (>> 2024.5.2), python3-dask (<< 2024.5.3~)

and in the binary python3-dask.distributed package similarly:

Depends: python3-dask (>> 2024.5.2), python3-dask (<< 2024.5.3~)

This forces the dask version to match the dask.distributed version. I
don't know how tight the version numbers need to be, but this works to
keep the packages in step with each other, and will prevent an updated
dask package from migrating if the dask.distributed package has not
been updated in parallel. Probably more effective than adding
something to README.source (though that will certainly help a bit).

Best wishes,

Julian

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Étienne Mollier, on 2024-06-14:

* napari is failing to build from source, but I haven't
checked yet whether this was caused by introduction of the
new dask or something else.

After further tests, this turns out to be a pre-existing bug,
and is not a regression introduced by the newer dask, so I
opened #1073504. I did not identify regressions introduced by
dask.distributed 2024.5.2 neither, at least not on amd64. This
is very encouraging.

Have a nice day, :)
--
.''`. Étienne Mollier <emollier@debian.org>
: :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da
`. `' sent from /dev/pts/2, please excuse my verbosity
`-

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEj5GyJ8fW8rGUjII2eTz2fo8NEdoFAmZvT2oACgkQeTz2fo8N Edqdrw/+OvZMGt25PIwS2mOQfPYNsJRRklBlEBMhvgBs7h9Xyj9IcbfTT7KAnGUT BekYRc38mM9a1GA3ALCJ91uw29G4MrsbvRGdqo7IHoYjy5t/rshNPZqiH8BupQiR uPuBUA2/J6lvgqrhDD/DxP6D5kXOtgdZkHT88t/JZ7bb3EikHU9gGBv4amoP7pxl 2JDRacQxEy7ZMz551qRyIfoS88sbvbCB2fMsTQuKkdun08miFQkQsW9+zL6co9wk SwUr20tMEwgcgXJ4JQblore0Y1xwNjguiZiOJg7oSOJghp2foiA/otyaFQKJrIy7 K5KdfAhh8tAlhi7qqcduNQ5HSn28BRLuBq8p/mBve4F2izDphG+v+VGAKFq/UBr5 CJBF3sTyGTqtV4ynAD9J39NqegSyuLo0GwvkS9ku16W5mK1WpzS8CuGhEO37mpen 1pKi+r2SBKbic6TiiWDQklhUFj2Awc9unRPl6gGKMhaB5RKInhhWJKhxVafw++f5 Cw/ULB7GWkuUwFpvI8VgHrVWwJUTXMF+c2deKsF1TgqdnpV0uShzUG6Cgj5aF4EN aduzm4RP055kOmosh1QK0KnjlAPbjHJjaLN4tCEzdXqsbtPCEpZc8YYjG3HeoGxd 4EUTW4qfldXSnSsYYtP9jwSLloURHnthLleDCePCbCSZWNyorvs=
=2741
-----END PGP SIG

Hi Julian,

Julian Gilbey, on 2024-06-16:

On Sat, Jun 15, 2024 at 10:50:17AM +0200, Étienne Mollier wrote:

Historically it was pretty important to dask and dask.distributed to be released together, upstream intends them to be matching versions, but I didn't know how to set the the dependnecy version strings to require that.

It makes sense. The construction pretty much looks like the
latter is supposed to be a Python submodule of the former.

You could do something like this in the dask.distributed source
package:

Source: dask.distributed
Build-Depends: python3-dask (>> 2024.5.2), python3-dask (<< 2024.5.3~)

and in the binary python3-dask.distributed package similarly:

Depends: python3-dask (>> 2024.5.2), python3-dask (<< 2024.5.3~)

This forces the dask version to match the dask.distributed version. I
don't know how tight the version numbers need to be, but this works to
keep the packages in step with each other, and will prevent an updated
dask package from migrating if the dask.distributed package has not
been updated in parallel. Probably more effective than adding
something to README.source (though that will certainly help a bit).

Thanks for the hint! I was not initially happy with the manual
setting of the version, at least for the build dependency, but
thinking a second time about this, it would prompt upload
attempts for newer upstream versions to lookup dask as well as dask.distributed. So all in all, this is a fair plan.

Have a nice day, :)
--
.''`. Étienne Mollier <emollier@debian.org>
: :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da
`. `' sent from /dev/pts/2, please excuse my verbosity
`- on air: Refugee - Grand Canyon: The Source/Theme for t…

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEj5GyJ8fW8rGUjII2eTz2fo8NEdoFAmZvUPwACgkQeTz2fo8N EdqUaRAAvGNsGYPgA9DbwLjaEMSy2g0EaDOgoGSjdqGrTrqqCjTCErc1yH8+AnnM TT/XPBYgRuebmF2NoU8u2Bdhf0u9KHQ+VF4dJiQelMeOjWFN5dOI4qq86iOpySiW ym4AxwhqR6O/RZDfy+dO92EVF2ci/DfrE7Ro/koYR3Cmtfuo46yK9S7uMg3WNVSr ILc3/bogZBUXDZE0xuBGCk7hEmJMJ++Dq77GrgUdZbehug2yDOS/x32/kEyevk4k H8jKgUO4omcn4FADA3CKtDOqbLs4hhyJWgv/VK5c8PV/6ykj82bsFDV/yE7nEJGS ASmgAsFOp1+S/rUJCdnqtkSOxBgKpEAJ1qF1Ywkiz117FcaS5qFPtylKg59nfKvR KYhQHVoXrRPTcP463LZS79qfPQkogxQ5BPI9G22tPt8+K10aP8utxPHhTpZQdKvK ZyMbRXHMkHivg5VWAXTURPR4wFqO4GZ65eu9DRdpbPxJeieLyy+Gvm1LdGyPHEVr eijEFTH8XaRpOHCLNPt4aApQFI9bEFR0aRozikmPKERKy5sO2dCk1y5nNHA7ssoX OV7bd3REZ3EIh3ADP4oN4qody0ZoVtn47InsUxZ1bQpK3fS95g7Cvuvh5cUGnxmo ldkTzjbl/df4FtfX

On Sun, Jun 16, 2024 at 10:57:22PM +0200, Étienne Mollier wrote:

Thank you for your help with dask documentation, took time to
polish what I could and uploaded dask. dask.distributed upload
is coming soon, just the time for the last pass of local build
and tests to finish.

Have a nice day, :)

Hi Étienne,

Unfortunately, the new dask.distributed FTBFS: https://buildd.debian.org/status/package.php?p=dask.distributed

:-(

Julian

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Julian,

Julian Gilbey, on 2024-06-17:

On Sun, Jun 16, 2024 at 10:57:22PM +0200, Étienne Mollier wrote:

Thank you for your help with dask documentation, took time to
polish what I could and uploaded dask. dask.distributed upload
is coming soon, just the time for the last pass of local build
and tests to finish.

Have a nice day, :)

Hi Étienne,

Unfortunately, the new dask.distributed FTBFS: https://buildd.debian.org/status/package.php?p=dask.distributed

Hmm, I see, it looks like my "isolation" by erasing resov.conf
is just insufficient to catch attempts to make direct use of IP
addresses. I retried with an unshare chroot, and I already
start seeing the same test items failing.

This prompted me to adjust my configuration to forcefully use my
lingering unshare a bit more often. Thanks for the follow up!

Have a nice day, :)
--
.''`. Étienne Mollier <emollier@debian.org>
: :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da
`. `' sent from /dev/pts/7, please excuse my verbosity
`- on air: Rush - Fly By Night

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEj5GyJ8fW8rGUjII2eTz2fo8NEdoFAmZweZwACgkQeTz2fo8N Edo0RQ//XZ9EomVxtE+fZiKEZQt2xGV/mV7+kQeDyHCrsu+VSibFpx/KJ63lhpbg OC6O/Syr4xPpcu6Qw8tG5nZ4Rwcfa2jM/+LSUkvkwpd/2YV9Amv6svztAFz6YPsV q/nrkcZ0j3K2BY50W/9v4lebJnwXN5psmdaDS/q3YpCLHttkjdKx+p2ihmia5+qO rlt7vDp9jmdeIcAtyRhO9rjdiIkxRTUe88fmdkwdxDV5hHe0KHResFKCJ8ESvqyz PIJgrCTJLDQtUveyIwc2Gcv3jhMbl+1QqMS7aETIahfZmW8d+SpZkbDU/sDZ2BIH cFVDBoflOSUdsndNsRBqnFJly6SuA+/6G4F9gSauiwRkVjYKo+8IPRwLQ81FURSk aHa8Ydc9Sf9ZkRoAYvEMCk7PWQH/Tx3KLim/JqVkdC8EC34xAG0nhJR7jreGbxVd vRgnTY7RV1MsQVp6iOVXk8opitQqEJlW4EB9lGIp0NFsapTjUgT2lPIknqnY62Zc z4W1dhLkW+4AhY2GnidtTtZDmhujPPHpNvY8JThEGDHuTjlbpjB6Zfipq6AkgcQp ibt6clvxmnV0BCCE801jj4tJdqvHULz5CTLCYLUmECR2ZP3Cujsq4pALLz7CJOyf BJCEqKbsivSoiZi03ife4cHAA05NUW5lHQWGBvb/o4qWoV