I had been trying to update dask to newer version (2021.11.1), but it looks like the issue you referenced is still open.
I tried the change they suggested in an i386 sbuild chroot and most of the errors went away. Though there was one test failure. "c.astype(np.int64, copy=False), k from np.int64 to np.intp fixes the issue?" Though since new dask version depended on a new sphinx plugin that I had to submit to the NEW queue I tried the patch on i386 with 2021.09.1 and those tests seemed to work. Let me see if 2021.09.1 works on amd64 and if it does I'll make a new 2021.09.1 release that's compatible with pandas 1.3 before trying to figure out whats going on with newer versions Diane On Wed, 2021-12-08 at 22:07 +0000, Rebecca N. Palmer wrote: > Package: python3-dask > Version: 2021.09.1+dfsg-1 > Severity: serious > Tags: patch > Control: forwarded -1 https://github.com/dask/dask/issues/8169 > (actually found independently) > > With pandas 1.3 (currently in unstable, see #999415), the dask > autopkgtest fails on armhf and i386 with > > /usr/lib/python3/dist-packages/dask/dataframe/backends.py:358: in > group_split_pandas > indexer, locations = pd._libs.algos.groupsort_indexer( > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > _ > _ _ _ _ > > > ??? > E ValueError: Buffer dtype mismatch, expected 'const intp_t' but > got > 'long long' > > pandas/_libs/algos.pyx:194: ValueError > > Full log: > https://ci.debian.net/data/autopkgtest/testing/armhf/d/dask/17399418/log.gz > > The above upstream bug says changing np.int64 to np.intp at > https://sources.debian.org/src/dask/2021.09.1+dfsg-1/dask/dataframe/backends.py/#L359 > > is a fix (which they haven't used, it's incompatible with earlier > pandas, but we don't need to care about that). >
