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
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).
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
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
Thanks - I plan to look at this tomorrow.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
what's now in Salsa should be.
(but please do *not* upload that right now, it is rather likely to have
(unrelated) issues)
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
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.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
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
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):
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 pending
This appears to be fixed in Salsa (before I reported it) - is there any
reason not to upload this now?
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
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.
--
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.
--
seaborn has now been fixed. I intend to look at python-altair later.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
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
The above by itself wasn't enough, but what I have now pushed to Salsa
is. Please upload it.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
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.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
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.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
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
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
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: 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.
--
debian-science-maintainers mailing list
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.
--
debian-science-maintainers mailing list
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).
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
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.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
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.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
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.
--
debian-science-maintainers
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.
--
debian-science-maintainers mailing list
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
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
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.
--
debian-science-maintainers mailing list
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
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
Source: openpyxl
Version: 3.0.9-2
Severity: serious
licensecheck -r --copyright . on openpyxl finds these:
./openpyxl/formatting/tests/data/conditional-formatting.xlsx: UNKNOWN
[Copyright: 2007 Apple Inc.]
./openpyxl/reader/tests/data/complex-styles.xlsx: UNKNOWN
[Copyright: 2007 Apple
Package: python3-numexpr
Version: 2.8.6-2
Severity: serious
Justification: block testing migration of a known security hole
Tags: patch
numexpr 2.8.5 introduced a security check, which was initially buggy
enough to break pyfai and pandas (#1049326). Fixes for this were sent
upstream, but only
Package: python3-openpyxl
Version: 3.0.9-2
Severity: wishlist
Control: affects -1 python3-pandas
Upstream pandas 2.1 will only use openpyxl >= 3.0.10. If I override
this to accept Debian's 3.0.9, I get 2 test failures that plausibly
might be caused by it (but I haven't actually tried it with
Control: severity -1 serious
That wasn't a fix - log with pocl 4:
https://ci.debian.net/data/autopkgtest/testing/i386/libg/libgpuarray/37023715/log.gz
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
numba also crashes on mips64el, mipsel and armhf (and s390x but that was
already known; not amd64, i386 or ppc64el). However, I agree that arm64
is a good place to start trying to fix this, given how common it is.
For examples, see the pandas 2.0.3+dfsg-3 / 1.5.3+dfsg-5 build logs.
Given the
On further thought, both of those probably should be fixed in numexpr -
I have pushed them to fix1049326.
With those changes to numexpr, the new pandas (1.5.3+dfsg-5) should
build; pytables will still also need its upstream fix.
--
debian-science-maintainers mailing list
stringToExpression() in this numexpr patch needs a default of True for
sanitize (like the others already have), because pytables calls that
directly:
https://salsa.debian.org/science-team/pandas/-/jobs/4571451/raw
(The other failure in there is one I plan to fix.)
The two pytables tests with
Given that this is a security feature and we hence want it in quickly,
I'd consider that patch enough to xfail/disable the remaining issues in
pandas, but discussions with upstream are ongoing.
(It also won't do anything about the pytables breakage, known upstream
as #1044.)
--
I pushed this fix to Salsa as the 'fix1049326' branch - it isn't enough
to fix pandas by itself, but is plausibly an improvement.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
Numexpr upstream have what they think is a fix for the exception issue
(though not the overflow change), but it hasn't been tested yet:
https://github.com/pydata/numexpr/issues/442
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
Control: forwarded -1 https://github.com/pandas-dev/pandas/issues/54546
Control: affects -1 python3-pandas
There's actually *two* bugs here: an exception in eval/query,
https://github.com/pandas-dev/pandas/issues/54449, and a changed result
with integer overflow,
Package: python3-numexpr
Version: 2.8.5-1
Severity: serious
Control: forwarded -1 https://github.com/pandas-dev/pandas/issues/54449
(actually they found it first)
I only have actual logs for 2.0.x, but I suspect 1.5.x is also affected.
As a short term fix, it may be possible to disable pandas'
Note also that PyPI tzdata includes old timezone names (US/Eastern etc)
that were recently moved to tzdata-legacy in Debian, and that the pandas
tests/examples heavily use these names.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
Package: src:esda
Version: 2.4.3-4
Control: block 1043240 by -1
esda fails to build with pandas 2.0, currently in experimental.
Build log:
https://launchpadlibrarian.net/680699664/buildlog_ubuntu-mantic-amd64.esda_2.4.3-4_BUILDING.txt.gz
A common source of failures is that pandas.util.testing
Package: src:python-ulmo
Version: 0.8.8+dfsg1-1.1
Control: block 1043240 by -1
python-ulmo fails its autopkgtest with pandas 2.0, currently in
experimental.
Log:
https://ci.debian.net/data/autopkgtest/unstable/amd64/p/python-ulmo/36575876/log.gz
A common source of failures is that
Package: src:dials
Version: 3.12.1+dfsg3-5
Control: block 1043240 by -1
dials fails its autopkgtest with pandas 2.0, currently in experimental.
Log:
https://ci.debian.net/data/autopkgtest/unstable/amd64/d/dials/36575801/log.gz
A common source of failures is that pandas.util.testing has been
dask has now been updated to a pandas 2 compatible version, allowing me
to test its reverse dependencies. This found that intake and
xarray-sentinel are broken by pandas 2, while python-xarray is already
broken for other reasons.
A common source of failures is that pandas.util.testing has
Package: python3-pandas
Version: 2.0.3+dfsg-1
Control: notfound -1 1.5.3+dfsg-4
Control: block 1043240 by -1
python3-pip and similar Python tools usually count system python3-X as
satisfying Python dependencies on X. Hence, upstream build scripts that
attempt to pip install X can usually work
These packages appear to be broken *by* pandas 2.0 - I will file
individual bugs when I have time:
augur cnvkit dask dials dyda emperor esda influxdb-python jsonpickle
macsyfinder mirtop mlpack pyranges python-altair python-anndata
python-biom-format python-feather-format python-nanoget
Package: python3-pandas
Version: 1.5.3+dfsg-4
Severity: wishlist
Control: block -1 by 1043093
pandas 2.0 is now in experimental. However (as you might expect from
that version number), it breaks around 40 other packages, and it is
hence likely to be some time before it moves to unstable.
This does seem to have worked: the openblas build log no longer contains
FATAL ERROR.
Hence, please give back statsmodels on mips64el. (DMs aren't allowed to
use the self-service link.)
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
Control: tags -1 upstream
Upstream CI's mips64 qemu test has what look like the same FATAL ERRORs,
in MIPS64_GENERIC but not SICORTEX, but is still listed as passing.
Which suggests that they also have both parts of this bug (wrong answers
on mips64el, and errors not actually failing the
The most obviously relevant
change between those is that the installed BLAS changed from atlas to
openblas.
It looks like this wasn't a change of default, but that experimental
uses libatlas and unstable uses libopenblas.
(I don't know why, as the obvious dependency chain is src:statsmodels
Package: libopenblas0-pthread
Version: 0.3.23+ds-2
Control: affects -1 src:statsmodels
Severity: serious
Justification: the default BLAS should NOT silently give wrong answers
(i.e. if there's no easy way to actually fix this, please switch the
default on mips64el back to atlas, and consider
Control: tags -1 fixed-upstream patch
This is probably caused by the new fsspec version, and is also seen in
autopkgtest:
https://ci.debian.net/data/autopkgtest/testing/amd64/p/pandas/36146393/log.gz
Upstream fix:
Control: reopen -1 1026539
theano has been mostly abandoned upstream since 2018. (The Aesara fork
is not abandoned, but includes interface changes including the import
name, so would break reverse dependencies not specifically altered for it.)
It is currently broken (FTBFS due to multiple
While that particular problem is easy to fix, there are other
incompatibilities that aren't (see #1026539, #1027215) and I intend to
let autoremoval happen.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
On 14/03/2023 10:29, Andreas Beckmann wrote:
This should have been addressed in pyopencl.
Do you mean pocl or did you intend to send that to #1030298?
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
On 03/03/2023 06:00, Andreas Tille wrote:
Ahh, so aesara is not really a "fork" but a "rename"?
The original is abandoned (no new development since 2017, and now mostly
unmaintained, which is probably why it has this kind of bug). Aesara is
a continuation by a new upstream (possibly one
On 02/03/2023 10:38, Andreas Tille wrote:
I admit I do not see any good reason to stick to the old version if we
decided before that keras/deepnano are no real blockers to even drop
theano. Thus I was considering it more promising to spent my time on
the latest version.
1.1.2 isn't the latest
I agree that switching to Aesara is probably the only reasonable option
other than removal. (I'd given up on trying to fix 1.0, and was
intending to let removal happen.)
However, it's a much bigger change than is normally allowed in bookworm
at this point. (1.1 includes multiple breaking
Control: reassign -1 python3-xlrd
Control: affects -1 python3-pandas
Control: retitle -1 pandas can't open xls (not xlsx) files, xlrd too old
Then yes, you do need xlrd. As Debian is currently in freeze, I suggest
installing it from PyPI (warning, this doesn't automatically install
security
Is the file you're trying to open .xlsx or .xls? Do you have
python3-openpyxl installed? If .xlsx and no, try installing it.
(python3-)xlrd 2.0+ can only open .xls files, not .xlsx. Hence, pandas
1.5+ read_excel() always uses (python3-)openpyxl for .xlsx files.
python3-pandas already
Possibly useful here: gdb disassemble works inside pocl kernels, see
#920497 for an example.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Control: reassign -1 src:pocl,src:libgpuarray
Control: found -1 pocl/3.1-3
Control: found -1 libgpuarray/0.7.6-13
Control: retitle -1 libgpuarray: i386 test fail with new pocl
The trigger is probably pocl, not clinfo. I don't yet know whether the
bug is in pocl or libgpuarray.
--
Package: science-numericalcomputation
Severity: minor
theano is abandoned upstream and is broken by numpy 1.24 (#1027215). It
is hence being removed from testing/next-stable, and probably from
unstable as well.
Hence, please stop listing it in this metapackage.
--
Control: merge -1 1030210 1030221
Not obviously known upstream.
It's due to the test passing an int64 array to np.bincount (which casts
to native-size int). Hence, we can probably get it to pass by
explicitly casting to int32 in the test code, but I haven't tried that yet.
I don't know
Package: python3-statsmodels
Version: 0.13.5+dfsg-4
Severity: serious
Since scipy 1.10, some statsmodels tests fail on 32-bit with a message
that int64 -> int32 casting is unsafe. I haven't yet had time to
investigate further.
--
debian-science-maintainers mailing list
Control: tags -1 patch
Control: unblock -1 by 1011225
(Block possibly added by mistake - these don't look related.)
This patch is now available as a Salsa merge request, and passed
build+autopkgtest there.
--
debian-science-maintainers mailing list
Control: tags 1029701 fixed-upstream
Full log:
https://ci.debian.net/data/autopkgtest/unstable/amd64/s/scikit-learn/30693526/log.gz
There appear to be at least 2 separate failures here, both known and
probably fixed upstream. So yes, 'new upstream version' is the first
thing to try, but
Control: reopen -1
Control: found -1 2023.01.0-1
This patch was dropped in the next upload (probably by accident), and
hence this bug has reappeared.
It is currently listed as blocking pandas from testing, though I'm not
sure why (it isn't obvious why pandas and xarray would have to go
The remaining autopkgtest failures blocking pandas are:
- dipy/amd64 and snakemake/i386 look like random flakiness: please retry
them. (I think DMs can't use the self-service interface.) Or for dipy,
see #1029533 for a possible fix.
- python-xarray/i386 looks like xarray not pandas: see
Control: tags -1 pending
Looks like rounding error in a test; ignored in Salsa.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
theano has been mostly abandoned upstream since 2018. (The Aesara fork
is not abandoned, but includes interface changes including the import
name, so would break reverse dependencies not specifically altered for it.)
Its reverse dependencies are keras, deepnano and invesalius.
It is
Control: severity 1025393 serious
Control: severity 1024820 serious
The autopkgtest fails (except statsmodels, which I just fixed) are
packages that are test-uninstallable because pandas 1.5 Breaks: current
dask. (This is #1025393, but some of its discussion was accidentally
sent to #1027254
Package: python3-pandas
Version: 1.5.2+dfsg-4
Severity: serious
Looks like the numpy 1.24 issues I knew about weren't the only ones.
Fix in progress in Salsa.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
Package: python3-pygpu
Version: 0.7.6-12
Severity: grave
numpy 1.24 no longer has np.bool, which makes pygpu fail to import:
pygpu/dtypes.py:74: in _fill_dtype_registry
register_dtype(np.bool, ["ga_bool", "bool"])
numpy/__init__.py:284: in __getattr__
raise AttributeError("module {!r}
Control: forwarded -1 https://github.com/ulmo-dev/ulmo/pull/214
Control: severity -1 serious
Untested patch at the above link. pandas 1.5 should be uploaded to
unstable today, making this RC.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
skbio is fixed, ulmo is maybe fixed but untested.
dask is unclear (see #1027254 for details): it looks like it's probably
fixable, but I don't have an actual working fix yet. There has been no
response from its maintainers.
--
debian-science-maintainers mailing list
On 06/01/2023 09:16, Nilesh Patra wrote:
The version of dask is same since few months. What do you mean by new dask?
Current Debian dask (2022.02) fails its tests with pandas 1.5
(#1025393), and the obvious way to fix that (and #1027254) is to update
it to current upstream dask (2022.12),
Should this go ahead before the freeze? I think yes if the new dask
works, but am open to disagreement.
Issues this would fix:
python3.11 #1023965: We're currently ignoring these test failures.
Mystery autopkgtest failure (fails without any listed individual test
failure, started
Please do *not* upload theano 1.12 to unstable - it's the Aesara
version, which may seriously break backward compatibility.
I haven't had time to properly look at this bug yet.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
Control: reopen -1
On 13/11/2022 15:02, Rebecca N. Palmer wrote:
It looks like this has been fixed somewhere other than the ulmo package
(I don't know where), as the autopkgtest now passes with pandas 1.4/1.5.
No it doesn't - it's being run with pandas 1.3 because pandas 1.5
declares
Control: severity -1 wishlist
Control: retitle -1 transition: pandas 1.3/1.4 -> 1.5
Control: tags -1 fixed-in-experimental
pandas 1.5.1 is now in experimental.
It appears to break emperor, q2templates and statsmodels. (Compared to
1.4; also python-skbio (#1017574) compared to 1.3.)
It also doesn't fail on the buildds. (The failed binNMU of statsmodels
for Python 3.11 is instead the expected result of trying to build
statsmodels on a Python version without pandas - pandas failed due to
#1023965.)
Is there anything special about the mass-rebuild environment that might
1 - 100 of 257 matches
Mail list logo
