Package: devscripts
Version: 2.23.4+deb12u1
(locally; also occurs at https://qa.debian.org/cgi-bin/watch, I don't
know what version that uses)
Gitlab (probably all up-to-date instances, not just gitlab.com) now
places its tarball download links inside Javascript, which breaks simple
d/watch
Control: tags -1 patch
My 0.9 package (see above link) passed reverse dependencies testing:
https://launchpad.net/~rebecca-palmer/+archive/ubuntu/tabulate0p9
Note that this is only a build test, not autopkgtest, and azure-cli,
pymatgen and python-django-ca are excluded as they do not exist in
I have an 0.9.0 package that builds, but I haven't finished testing it
yet, so do _not_ recommend uploading it right now:
https://salsa.debian.org/rnpalmer-guest/python-tabulate/-/tree/fix1070359?ref_type=heads
On 15/05/2024 23:49, Alexandre Detiste wrote:
The only change code-wise is the patch that was already in 1.3.5+ds1-3
Having now had time to look, I agree. This implies that changing the
minimum bottleneck version in pandas would work. However, as bottleneck
also has other reverse
Control: tags -1 patch
https://salsa.debian.org/python-team/packages/influxdb-python/-/merge_requests/2
Not *obviously* known upstream.
Control: affects 1070359 src:camelot-py
Control: affects 1070360 src:glueviz
As expected from the version number, this looks easier than the last
one: there are only 4 remaining failures and they all look easy to fix.
These are:
augur (#1071122)
camelot-py (tabulate too old #1070359)
glueviz
Source: influxdb-python
Version: 5.3.1-6
Severity: wishlist
Control: block 1069792 by -1
This package's tests fail with pandas 2.2, currently in experimental.
https://launchpadlibrarian.net/728496862/buildlog_ubuntu-oracular-amd64.influxdb-python_5.3.1-6_BUILDING.txt.gz
Source: augur
Version: 24.3.0-1
Severity: wishlist
Control: block 1069792 by -1
This package's tests fail with pandas 2.2, currently in experimental.
https://ci.debian.net/packages/a/augur/unstable/amd64/46551367/
I now have a 2.2 package that builds (but installs test_stata.dta
somewhere it shouldn't - reminder to self: fix that before uploading to
unstable).
Package: python3-blosc
Version: 1.11.1+ds1-2
Severity: wishlist
Control: affects -1 python3-pandas
Some pandas functionality is currently unavailable because Debian blosc
is too old; it requires >= 1.21.
Package: python3-bottleneck
Version: 1.3.5+ds1-3
Severity: wishlist
Control: block 1069792 by -1
(Not actually a hard block as it's not a hard Depends, but I'd prefer
not to lose the functionality that does require it.)
I would like to upgrade pandas to 2.2.x, but this will only use
Control: forwarded -1 https://github.com/dask/dask/pull/11035
Control: tags -1 fixed-upstream patch
Thanks and probably yes (but I haven't tested that fix myself), as while
it didn't happen in 3.11.8, it *does* happen in 3.11.9:
https://ci.debian.net/packages/d/dask/unstable/amd64/46185892/
Package: python3-tabulate
Version: 0.8.10-1
Severity: wishlist
Control: block 1069792 by -1
(Not actually a hard block as it's not a hard Depends, but I'd prefer
not to lose the functionality that does require it.)
I would like to upgrade pandas to 2.2.x, but this will only use tabulate
if it
Package: python3-pandas
Version: 2.1.4+dfsg-7
Severity: wishlist
Upstream have released pandas 2.2.
(Filing this now to have a bug number - I haven't actually uploaded to
experimental yet.)
Reverse dependencies to be tested:
abinit astropy augur azure-kusto-python bmtk bqplot busco
Source: topplot
Version: 0.2.2+repack-1
Tags: patch
Severity: serious
Justification: blocks testing migration of other packages
topplot tries to run its autopkgtest in all versions of Python (which is
good), but does not test-depend on all those versions of Python.
This previously worked
This bug is not *obviously* known to dask upstream, but their CI is
failing and I haven't checked why.
It happens only in Python 3.12, not 3.11:
https://ci.debian.net/packages/d/dask/unstable/amd64/45013666/
and still doesn't happen in testing, but does happen in mostly-testing
with
Control: unblock 1068104 by -1
Control: unblock 1068104 by 1068422
To avoid being blocked by this bug, the pandas version I just uploaded
temporarily disables the documentation.
This is also an option for any other affected packages that urgently
need to be uploaded. (I don't know whether
Package: python3-dask
Version: 2023.12.1+dfsg-2
Severity: serious
Control: affects -1 src:pandas
Control: block 1068104 by -1
Importing dask.dataframe currently fails with the error
TypeError: descriptor '__call__' for 'type' objects doesn't apply to a
'property' object
amd64
Control: tags -1 patch
Control: severity -1 serious
(probably makes nbconvert/nbsphinx unusable)
xml-html-clean is in
NEWhttps://ftp-master.debian.org/new/lxml-html-clean_0.1.0-1.html
Thanks - that and adding it to the Depends of python3-nbconvert should
fix this bug.
From codesearch,
Package: python3-nbconvert,python3-lxml
Version: 6.5.3-4,5.2.0-1
Control: affects -1 src:pandas
Control: affects -1 python3-nbsphinx
Control: block 1068104 by -1
The pandas documentation fails to build in current unstable with:
Running Sphinx v7.2.6
nbconvert not installed. Skipping notebooks.
Thanks - I plan to look at this tomorrow.
Control: reopen -1
Control: tags -1 pending
Control: tags 1066801 pending
Control: tags 1064384 pending
Sorry, that wasn't actually a fix, but what's now in Salsa should be.
Control: retitle -1 pandas: test-failing warning with new xarray
This is a warning being treated as an error, but the one in
test_to_xarray (probably due to the new version of xarray), not the
zoneinfo one. This is a FutureWarning, so it should be OK to *use* the
current pandas with the new
Control: forwarded -1 https://github.com/pydata/xarray/issues/7079
(actually found independently)
The above upstream report suggests that this is because netcdf-python is
no longer thread-safe.
The 3 random-autopkgtest-fail bugs (this, #1064326 and #1064370)
together seem to be more common
Remaining blockers for testing migration:
- python-ulmo #1044057: has a patch, please upload
- pydevd #1063274: unclear whether my patch breaks something else,
please leave alone for now
Status unclear:
- python-xarray: autopkgtest has failed 3 times, but all 3 are
(different) failures that
Is that a yes to>> Does just the patch (not the new upstream) also break
debugpy?or have you not tried specifically that?
(I'm looking for a quick fix for the autopkgtest fail to unblock the
pandas 2.x transition. I agree that upgrading to a new upstream is a
good idea in the long run.)
Package: python3-xarray
Version: 2023.12.0-3
The xarray autopkgtest sometimes (~20% of the time) fails with
RuntimeError: NetCDF: Not a valid ID
in tests/test_backends.py::TestOpenMFDatasetWithDataVarsAndCoordsKw
Unlike the other random failures, this seems to be amd64-specific.
Exactly which
Package: python3-xarray
Version: 2023.12.0-3
xarray sometimes (~10% of the time) segfaults in
tests/test_backends.py::test_open_mfdataset_manyfiles, usually
[netcdf4-20-True-None-5] but sometimes [netcdf4-20-True-5-5].
This has happened in both Python 3.11 and 3.12, and on various
Package: python3-xarray
Version: 2023.12.0-3
The xarray autopkgtest sometimes (~10% of the time) hangs in
test_roundtrip_coordinates, and hence fails with a timeout.
Example failure log (but this is _not_ specific to pandas 2.x):
Thank you for caring about not breaking other packages, and yes, that's
a good reason to not upload that new upstream for now.
Does just the patch (not the new upstream) also break debugpy? (It
shouldn't be able to, since it only touches test code.)
This has been merged but not uploaded - is there a reason it shouldn't
be, or have you just not had time?
tests.Description: Don't fail on malformed or changed test data
CDEC has malformed lines that pandas 1.4+ errors out on
(I'm not sure why earlier pandas didn't do the same);
GHCN has simply changed at the source.
Author: Rebecca N. Palmer (but upstream independently came up with the on_bad_lines part
Control: tags -1 patch
It does sometimes happen that fixing "can't import the tests" reveals
"the tests fail". Fixed in the Salsa merge request.
Control: tags -1 patch
See the Salsa merge request.
Control: tags -1 pending
This appears to be fixed in Salsa (before I reported it) - is there any
reason not to upload this now?
Package: python3-geopandas
Version: 0.14.3-1
Severity: serious
Control: block 1043240 by -1
In pandas 2.x (now in unstable), there are a few places where geopandas
uses native-size int but the plain pandas objects used as test
references are always int64, failing the test:
Package: python3-mdanalysis
Version: 2.5.0+dfsg1-2
The autopkgtest sometimes hangs at the 85% point, causing it to time out
and fail. (This is probably a hang and not just slowness, because when
it doesn't fail, this test doesn't take anywhere near that long.)
Control: block -1 by 1063274
Thank you for uploading those fixes.
Note to self: pandas will need another upload, to remove the numba B-D
and skip those tests (because numba is not in testing), and do something
about 'ignoredtests' being slow enough to time out in i386 and arm64.
Source: pydevd
Severity: serious
Tags: patch
A pydevd test uses DataFrame.applymap(), and fails because this now
raises a FutureWarning. Replacing it with DataFrame.map() as this
message suggests would probably fix it.
Package: python3-seaborn
Version: 0.13.2-1
Severity: serious
seaborn's autopkgtest failed on i386, with differences small enough that
they are plausibly rounding error (i.e. should be ignored, by using
*almost_equal instead of exact comparisons), but I haven't looked carefully.
On 03/02/2024 22:01, Andreas Tille wrote:
The point I was making in my mail was that I had trouble running the
tests in **latest** upstream version (5.2.0).
Sorry - I'd misread your previous message as you having tried 5.x, found
that it didn't work due to the missing dependency, and decided
It looks like this is at least two issues:
- Tests mix tabs and spaces, which is no longer allowed = upstream 2459
- Assumes f-strings are not tokenized, which they now are = upstream
2485/2588/2649
Fix in progress on the debian-v7 branch. (The main branch has 8.x,
which doesn't work due to
Please don't skip/xfail tests - my suggestion above is an actual fix:
https://salsa.debian.org/rnpalmer-guest/python-altair/-/tree/fix1044073?ref_type=heads
(In a fork because, despite its description, this is not actually a
debian-science package. The Salsa CI "fail" is because the *old*
My fixes are pushed to Salsa, but they're in a fork because this isn't a
debian-science package:
https://salsa.debian.org/rnpalmer-guest/influxdb-python
seaborn has now been fixed. I intend to look at python-altair later.
Note that this uncertainty is only around whether this is a complete fix
- even in the case where it's not, it *wouldn't* be actively worse than
doing nothing, though it would be hiding the problem.
I intend to upload pandas 2.x to unstable soon. These packages have a
patch in their bug - please upload them (I'm a DM, I can't do that), or
if you think this patch won't work or isn't a good idea, tell me why:
dials influxdb-python python-altair python-feather-format seaborn tqdm
In
Some looking through the code suggests that the precision is user-set
and hence constant within a single query, and hence that this fix is OK,
but I'm not entirely certain of that.
There are ways to make pandas 2.x accept mixed time format, but I think
they're 2.x _only_ and/or slow.
That turned out to be easier than it looked - fixing the easy one also
made the others go away. Please upload this:
https://salsa.debian.org/rnpalmer-guest/tqdm
Control: retitle 1058160 tqdm: tests failing/hanging in Python 3.12
That works for #1053946 (pandas 2.x), but #1058160 (python 3.12) is more
than a single hanging test, and it's not immediately obvious what should
be done.
Attempted fix (caution, currently just skips the hanging test) and
The above by itself wasn't enough, but what I have now pushed to Salsa
is. Please upload it.
That's not the only problem: some of the tests mix timestamps in
slightly different formats (with and without fractional seconds), which
is no longer allowed by default:
https://pandas.pydata.org/pandas-docs/version/2.1.4/whatsnew/v2.0.0.html#datetimes-are-now-parsed-with-a-consistent-format
On 22/01/2024 11:51, Julian Gilbey wrote:
Please could we wait until the "Python 3.12 is a supported version"
transition is completed?
How are you defining that? python3-defaults 3.11.6+ in testing? (I was
previously told 3.12-supporting pandas and numpy in testing, which has
happened. I
What, if anything, blocks the above fix from being applied now?
tqdm, influxdb-python and seaborn are the highest-popcon packages broken
by pandas 2.x.
Control: severity 1053943 1053939 1053942 1044053 1044056 serious
Control: severity 1044074 1053946 1044078 1044079 1044077 serious
Control: severity 1044071 1044067 1044068 1044055 1044060 serious
Control: severity 1044072 1044073 1044064 1053945 1044054 serious
Control: severity 1044076 1053940
These tests are now skipped in Debian (for unrelated reasons), so this
bug is no longer caught by the autopkgtest, but probably does still exist.
Package: ftp.debian.org
User: ftp.debian@packages.debian.org
Usertags: remove
libgpuarray has been de facto abandoned upstream since 2018, and is
unused in Debian since theano was removed (#1042574).
It currently has what may or may not be a wrong-answer bug (#1031414),
and two
pandas and statsmodels are currently using cython3-legacy. I left their
cython 3.0 bugs open when I made this change, as I do want to actually
switch them to cython 3.x at some point.
These bugs have now been raised to RC. Is this an intentional attempt
to remove cython3-legacy (which seems
Package: python3-pymatgen
Version: 2023.06.23+dfsg1-2
This autopkgtest, and particularly test_rotor_search_wrs, is slow enough
that it sometimes times out and fails. I think this is varying hardware
speed and not a random hang because failure seems to correlate with the
earlier tests taking
Package: python3-dipy
Version: 1.7.0-4
This autopkgtest, and particularly test_reconstruct_rumba, is slow
enough that it sometimes times out and fails. I think this is varying
hardware speed and not a random hang because failure seems to correlate
with the earlier tests taking longer.
This
On 10/12/2023 20:16, Julian Gilbey wrote:
> [...]I'd be in favour of doing the pandas
> transition now, which will allow Cython 3.0 to move into unstable.
Cython 3 is already in unstable; pandas is currently using cython-legacy.
And yes, my list of packages broken by pandas 2.x is those
Control: retitle -1 cfgrib: test failure - can't find eccodes
Because we now enforce that build-depends of testing must be in testing,
this bug is blocking python-xarray and hence pandas from testing, so is
more important than this package's popcon would suggest.
I consider it likely that
At least on arm64, this appears to be a crash in a @numba.jit function.
Given numba's known issues on non-x86 (e.g. #1033907), this suggests
that actually fixing it _may_ not be reasonable.
In pandas I don't recommend/build/test-depend on numba on the problem
architectures, but python-sparse
Control: tags -1 fixed-upstream
This was fixed upstream by
https://github.com/pydata/sparse/commit/266af7307b5232a37daa1d7659f02faf6a42e46e
. It still exists here because
debian/patches/fix-test-fails-on-i386.patch effectively reverses that
fix, possibly by accident.
libgpuarray has been de facto abandoned upstream since 2018, and is
currently unused in Debian. (Its original user was theano, which was
removed in #1042574.)
It currently has what may or may not be a wrong-answer bug (#1031414),
and two broken-by-transition bugs. (The latter two _might_ be
Control: block -1 by 1043240
Control: tags -1 fixed-upstream fixed-in-experimental
pandas 2.1.4 in experimental uses Cython 3, without known issues. We
are currently discussing (in #1043240) whether to move that version to
unstable, given that it would cause other breakage.
I'd like to move forward with the pandas 1.5 -> 2.1 transition
reasonably soon.
Given that pandas 2.x is *not* required for Python 3.12 (but is required
for Cython 3.0), should we wait for the Python 3.12 transition to be
done first?
These are broken by pandas 2.x and have a possible (but
Control: unblock 1043240 by 1044050
Control: severity 1044050 serious
Control: merge 1044050 1050623
Control: retitle -1 intake: newlines in error messages
Control: tags -1 patch
On closer inspection, that's not pandas 2.x related, it's the previously
seen failure to handle error messages
Control: severity -1 important
(We would like to transition to pandas 2.1 fairly soon.)
These packages are attempting to use .iteritems() on pandas objects,
which no longer exists. This can probably be fixed by using .items()
instead.
Control: severity -1 important
(We would like to transition to pandas 2.1 fairly soon.)
Replacing all instances of pandas.util.testing with pandas.testing
should fix the currently visible bug, but I haven't tried it so I don't
know whether there are also other bugs.
Control: severity -1 important
(We would like to transition to pandas 2.1 fairly soon.)
Ignoring these warnings would probably work for now.
This is not obviously known upstream, but updating to a newer upstream
version might still be worth trying.
Control: severity -1 important
(We would like to transition to pandas 2.1 fairly soon.)
This *might* be fixed by https://github.com/dask/dask/pull/10439 and/or
https://github.com/dask/dask/pull/10531
It might be best to update to a new upstream version, which would
include those and also
Control: severity -1 important
(We would like to transition to pandas 2.1 fairly soon.)
This bug can probably be fixed by replacing all 3 instances of
pandas.util.testing with pandas.testing.
There are also some (unrelated) Python 3.12 issues:
self.assertRaisesRegexp ->
Control: severity -1 normal
Control: retitle -1 pandas/pytables: ignored test fails with Python 3.12
Control: found -1 2.1.3+dfsg-1
Control: tags 1057805 pending
In 1.5.3+dfsg-8, these are ignored, so are no longer an FTBFS but are
still a bug. I don't know whether they're a pandas bug or a
That might not be enough: some of pandas' pytables-using tests are still
failing in Python 3.12 (see salsa-ci).
However, I don't know whether upgrading pytables to a newer upstream
would break anything else.
Control: unblock -1 by 1043240
The remaining test failures (all pytables-related) exist in both pandas
1.5 and 2.1, and do not appear to be known upstream.
If they are all crashes rather than wrong answers (which I think they
are), I intend to ignore them for now to unblock this, but still
Control: tags -1 fixed-upstream patch
Control: severity -1 important
(Raising severity because pandas 2.x is currently blocking Python 3.12)
This looks like the upstream fix (I haven't tried it in Debian):
https://github.com/mwaskom/seaborn/pull/3355
Upgrading to upstream 0.13 would probably
Control: reopen -1
That doesn't actually fix them all (and it's now unclear why I ever
thought it did - possibly mistaking 'has a python3.12 package' for
'tests with python3.12 by default'?), but at least the ones that are
left all look like exceptions not wrong answers.
I intend to look
This is also known as LP#2043284; upstream #8961 attempts to fix it, but
isn't enough by itself (see salsa-ci for logs).
Control: severity -1 wishlist
Switched to cython3-legacy for now.
I do want to actually fix this at some point, but it probably makes
sense for that to be after the pandas 2.x transition.
I retried the arm64 test and it passed, so it's probably just a random
hang (I've seen those before in pytest). Hence, I now _do_ suggest
uploading current Salsa.
This fix worked but the new upstream version added another similar
issue, so s390x failed again.
I have pushed a fix for this, and enabled allow-stderr to fix armel
(error output from an already-xfailed test). I don't know what's
causing the hang on arm64, so please do _not_ upload this just
I have added what should be fixes for #1053700 and #1044869, but they
are currently untested as salsa-ci only runs the autopkgtest on amd64.
#1050854 appears to have been fixed (or at least xfailed - it passed on
salsa-ci but they say it's flaky) by upstream.
Control: tags -1 patch
These all come from xarray/tests/test_coding_times.py, and are probably
fixable by replacing both instances of ("M8[ns]" if
sys.byteorder=='big' else "haven't actually tried that.
This bug is now a crash (not the original error message):
https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-xarray/39962554/log.gz
I don't know whether the same patch still works.
The Salsa repository now appears to be up to date.
You probably also want to include the fixes for the
Control: tags -1 patch
This patch has been probably-by-accident dropped again, and hence this
bug has reappeared again:
https://ci.debian.net/data/autopkgtest/testing/i386/p/python-xarray/39962705/log.gz
Re-adding it would probably work, but I haven't actually tried that.
Package: python3-pandas
Version: 1.5.3+dfsg-6
Tags: fixed-upstream fixed-in-experimental
User: debian-pyt...@lists.debian.org
Usertags: python3.12
Control: block -1 by 1043240
Control: forwarded -1 https://github.com/pandas-dev/pandas/issues/53665
(actually found independently)
pandas 1.5 FTBFS
Package: python3-xlsxwriter
Version: 3.0.2-2
Severity: wishlist
Tags: fixed-upstream
Upstream pandas 2.1 will only use xlsxwriter >= 3.0.3. Nothing
obviously breaks if I override this to accept Debian's 3.0.2, but it
might be better to actually update xlsxwriter.
astropy isn't actually a regression (i.e. it's probably _a_ bug, but
unrelated to pandas 2.x), and python-hypothesis appears to be fixed (by
upstream, in 6.83.1). I have filed individual bugs for the others.
Package: src:patsy
Version: 0.5.3-1
Control: block 1043240 by -1
patsy fails to build with pandas 2.1, currently in experimental.
Log:
https://launchpad.net/~rebecca-palmer/+archive/ubuntu/pandas2p1/+build/26770725/+files/buildlog_ubuntu-mantic-amd64.patsy_0.5.3-1_BUILDING.txt.gz
A common
Package: src:tqdm
Version: 4.64.1-1
Control: block 1043240 by -1
tqdm fails to build with pandas 2.1, currently in experimental.
Log:
https://launchpad.net/~rebecca-palmer/+archive/ubuntu/pandas2p1/+build/26770822/+files/buildlog_ubuntu-mantic-amd64.tqdm_4.64.1-1_BUILDING.txt.gz
A common
Package: src:dask
Version: 2023.8.0+dfsg-2
Control: block 1043240 by -1
dask fails its autopkgtest with pandas 2.1, currently in experimental.
Log:
https://ci.debian.net/data/autopkgtest/unstable/amd64/d/dask/38997774/log.gz
A common source of failures is new pandas FutureWarnings in tests
Package: src:seaborn
Version: 0.12.2-1
Control: block 1043240 by -1
seaborn fails its tests with pandas 2.1, currently in experimental.
Logs:
https://ci.debian.net/data/autopkgtest/unstable/amd64/s/seaborn/38997875/log.gz
Package: src:q2-types
Version: 2023.7.0-1
Control: block 1043240 by -1
q2-types fails its autopkgtest with pandas 2.1, currently in experimental.
Log:
https://ci.debian.net/data/autopkgtest/unstable/amd64/q/q2-types/38997869/log.gz
A common source of failures is new pandas FutureWarnings in
Package: src:q2-taxa
Version: 2023.7.0+dfsg-1
Control: block 1043240 by -1
q2-taxa fails its autopkgtest with pandas 2.1, currently in experimental.
Log:
https://ci.debian.net/data/autopkgtest/unstable/amd64/q/q2-taxa/38997868/log.gz
A common source of failures is new pandas FutureWarnings in
Package: src:q2-demux
Version: 2023.7.0+dfsg-1
Control: block 1043240 by -1
q2-demux fails its autopkgtest with pandas 2.1, currently in experimental.
Log:
https://ci.debian.net/data/autopkgtest/unstable/amd64/q/q2-demux/38997862/log.gz
A common source of failures is new pandas FutureWarnings
Package: src:python-geopandas
Version: 0.14.0-1
Control: block 1043240 by -1
python-geopandas fails its autopkgtest with pandas 2.1, currently in
experimental.
Log:
https://ci.debian.net/data/autopkgtest/unstable/amd64/p/python-geopandas/38997837/log.gz
A common source of failures is new
Package: src:python-cooler
Version: 0.9.1-1
Control: block 1043240 by -1
python-cooler fails its autopkgtest with pandas 2.1, currently in
experimental.
Log:
https://ci.debian.net/data/autopkgtest/unstable/amd64/p/python-cooler/38997833/log.gz
A common source of failures is new pandas
Package: src:pymatgen
Version: 2023.06.23+dfsg1-2
Control: block 1043240 by -1
pymatgen fails its tests with pandas 2.1, currently in experimental.
Logs:
https://ci.debian.net/data/autopkgtest/unstable/amd64/p/pymatgen/38997822/log.gz
Control: retitle -1 transition: pandas 1.5 -> 2.1
pandas 2.1 is now in experimental. In addition to the above, it breaks
these packages:
astropy dask patsy pymatgen python-cooler python-geopandas q2-demux
q2-taxa q2-types seaborn tqdm
and maybe python-hypothesis.
(python-pauvre and sunpy
1 - 100 of 912 matches
Mail list logo
