A bot wrote:
Dependency installability problem for dask on all:
dask build-depends on:
- python3-pandas:amd64 (>= 0.19.0)
dask build-depends on:
- python3-distributed:amd64
python3-distributed depends on:
- python3-dask:amd64 (>= 2.9.0)
python3-pandas conflicts with:
- python3-dask:amd64 (< 2.11
On 19/10/2020 20:07, Stefano Rivera wrote:
Hi Rebecca (2020.10.19_11:51:33_-0700)
Or maybe not an actual regression...it's a ~5e-7 difference and one of the
things the patch does (at around dask/dataframe/tests/test_rolling.py:270)
is _tighten_ the tolerance on that test.
Hrm, I didn't see th
Or maybe not an actual regression...it's a ~5e-7 difference and one of
the things the patch does (at around
dask/dataframe/tests/test_rolling.py:270) is _tighten_ the tolerance on
that test.
I have filed a separate bug (#972516) for the fsspec issues.
_
Package: python3-dask
Version: 2.11.0+dfsg-1
Some of fsspec's functionality now requires python3-aiohttp, including
parts used in dask autopkgtests:
https://ci.debian.net/data/autopkgtest/testing/amd64/d/dask/7549002/log.gz
Some of these work if I add a test-dependency, but 2 continue to fail
ertionError
diff -Nru dask-2.11.0+dfsg/debian/changelog dask-2.11.0+dfsg/debian/changelog
--- dask-2.11.0+dfsg/debian/changelog 2020-02-26 21:01:52.0 +
+++ dask-2.11.0+dfsg/debian/changelog 2020-10-19 08:38:20.0 +0100
@@ -1,3 +1,10 @@
+dask (2.11.0+dfsg-1.1) UNRELEASED; urgency=me
The upstream patch doesn't even apply as-is; this version does, but I
don't have time right now to actually test it.
There's also a circular dependency problem, as dask indirectly
build-depends on itself and my new pandas makes it uninstallable.
Description: pandas 1.1 compatibility
Origin:
Control: severity 969648 serious
Control: tags 969650 pending
Control: tags 972033 pending
Python 3.9 related breakage has been declared RC, so if nobody objects,
I intend to upload pandas 1.1 to unstable (possibly tonight, but it
probably won't build before numpy and matplotlib are binNMUd fo
The linked upstream report says this went away in numpy 1.18.4, and the
tests in question now pass on debci.
___
Python-modules-team mailing list
Python-modules-team@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pytho
Control: block 972033 by 969650
This is now the only bug blocking pandas 1.1. Is there something wrong
with the above fix, or have you just not had time to try it?
Upgrading dask to a newer upstream version is also an option, but I
haven't checked if it would break anything else.
Python 3.
Package: python3-dask
Version: 2.11.0+dfsg-1
Tags: fixed-upstream
With pandas 1.1.x from experimental, dask fails 8 of its tests, at least
mostly datetime-related.
Log:
https://ci.debian.net/data/autopkgtest/unstable/amd64/d/dask/6900447/log.gz
Upstream fix (untested): https://github.com/da
The patch still works for me (on amd64, dpkg-buildpackage in a chroot
with experimental python3-pandas(-lib), sid everything else; keep the
existing pandas025.patch). Anything obviously different about your test
environment?
___
Python-modules-team
This fix causes Sphinx to fail if documenting an object whose
__getattr__ fails, e.g. flask.request. This causes at least snakemake
to FTBFS.
Details and fix:
https://github.com/sphinx-doc/sphinx/pull/7520
A workaround in failing packages is to add
autodoc_default_options = {'exclude-members'
On 09/02/2020 16:29, Diane Trout wrote:
Thanks for letting me know, I'll try working on it though i probably wont have
much time until tuesday.
Given the number of broken packages, it's likely to take longer than
that anyway.
Ubuntu freeze is on the 27th.
Once I have a fixed build should
Source: dask
Version: 2.8.1+dfsg-0.4
Control: tags -1 fixed-upstream
Control: block 950430 by -1
With pandas 1.0 from experimental, dask builds but its autopkgtest fails.
Upstream have several commits marked as related to pandas 1.0
compatibility: it looks like dask 2.10.1 is supposed to work w
Package: python3-feather-format
Version: 0.3.1+dfsg1-3
Control: tags -1 patch
Control: block 950430 by -1
Two tests fail with pandas 1.0 (from experimental):
==
ERROR: test_boolean_object_nulls
(feather.tests.test_reader.TestFe
On 18/11/2019 07:07, Matthias Klose wrote:
On 18.11.19 07:52, Alastair McKinstry wrote:
So I've uploaded a python-xarray 0.14.0-2 which passes on python3.7.
Its failing on python 3.8 but apparently due to pandas not ready on 3.8, so it
should be ok to pass as the transition completes.
I think
Ubuntu have dask 2.6.0 and fsspec, but still have a few autopkgtest
failures:
https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
dask itself - looks like trying to use a nonexistent temporary directory
pyfftw - looks like a test treating a new (unexpected) warni
0.25
Author: Rebecca N. Palmer
Bug-Debian: https://bugs.debian.org/943925
Forwarded: not-needed (upstream have switched to pyarrow)
--- python-feather-format-0.3.1+dfsg1.orig/feather/api.py
+++ python-feather-format-0.3.1+dfsg1/feather/api.py
@@ -15,6 +15,7 @@
import six
from distutils.version
Control: severity -1 serious
python-pandas has now been removed, so these packages are now
BD-Uninstallable.
___
Python-modules-team mailing list
Python-modules-team@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pyt
Control: severity -1 important
Python 3.8 is being added to unstable's supported versions (#942106).
As discussed in #931557, pandas in sid (0.23) doesn't support Python
3.8. pandas in experimental (0.25) does, but contains some API breaks
and doesn't support Python 2, triggering these bugs.
Package: python3-feather-format
Version: 0.3.1+dfsg1-2
Control: block 931557 by -1
With python3-pandas 0.25, the build fails with these test failures:
==
ERROR: test_boolean_object_nulls
(feather.tests.test_reader.TestFeatherR
+
+ * Stop build-depending on python-pandas,
+and fix resulting test issues.
+
+ -- Rebecca N. Palmer Thu, 31 Oct 2019 21:42:13
+
+
python-apptools (4.4.0-3) unstable; urgency=medium
* Fixing broken links in python-apptools-doc
diff -Nru python-apptools-4.4.0/debian/control
python-apptools
Assuming we're talking about
https://salsa.debian.org/python-team/modules/dask/blob/experimental/debian/patches/use-local-intersphinx.patch
I think the actual problem is on the numpy line: it adds the local
inventory but doesn't remove the online one, so the tuple is too long.
(I haven't actua
Source: sphinx
Version: 1.7.5-1
Severity: serious
Control: tags -1 patch
Control: affects -1 src:theano src:python-jira
(These are the ones I've actually checked; I suspect most/all of the
~100 packages that build-depend on *-sphinx-rtd-theme are affected.)
sphinx's included themes have layout.ht
24 matches
Mail list logo
