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 source
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 that
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
https://launchpad.net/~rebecca-palmer/+archive/ubuntu/pandas2p1/+build/267
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 tes
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 t
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 i
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 pand
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 FutureW
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
https://launchpad.net/~rebecca-palmer/+archive/ubuntu/pandas
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 are
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 Inc.]
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
Salsa has 0.8.10, but it's been there for some time and I don't know why
it hasn't been uploaded.
Package: python3-tabulate
Version: 0.8.9-1
Severity: wishlist
Upstream pandas 2.1 will only use tabulate >= 0.8.10. Nothing obviously
breaks if I override this to accept Debian's 0.8.9, but it might be
better to actually update tabulate.
(At least to the latest 0.8.x - I don't know whether g
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 a
Package: python3-sphinx
Version: 5.3.0-7
Severity: wishlist
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fileordering
When the same function has two entries in the table of contents, that
function's documentation page may be generated with the table of
contents open to either of
Package: python3-nbclient
Version: 0.8.0-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
By default, nbclient includes timestamps in its output, which makes
packages built with it (e.g. python-pandas-doc) unreproducible.
It provides a rec
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
Package: src:emperor
Version: 1.0.3+ds-7
Control: block 1043240 by -1
emperor fails to build with pandas 2.0, currently in experimental.
Build log:
https://launchpadlibrarian.net/682917876/buildlog_ubuntu-mantic-amd64.emperor_1.0.3+ds-7_BUILDING.txt.gz
A common source of failures is that pandas
Control: tags -1 pending
Fixed in Salsa, but please do NOT upload that version as-is (it FTBFS
for an unrelated reason).
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.
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.
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
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, https://github.com/pandas-dev/p
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' n
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.
Package: src:augur
Version: 22.1.0-1
Control: block 1043240 by -1
augur fails to build with pandas 2.0, currently in experimental.
Build log:
https://launchpadlibrarian.net/680698719/buildlog_ubuntu-mantic-amd64.augur_22.1.0-1_BUILDING.txt.gz
Autopkgtest log:
https://ci.debian.net/data/autopkgt
Package: src:cnvkit
Version: 0.9.9-2
Control: block 1043240 by -1
cnvkit fails to build with pandas 2.0, currently in experimental.
Build log:
https://launchpadlibrarian.net/680699189/buildlog_ubuntu-mantic-amd64.cnvkit_0.9.9-2_BUILDING.txt.gz
Autopkgtest log:
https://ci.debian.net/data/autopkg
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 h
Package: src:influxdb-python
Version: 5.3.1-3
Control: block 1043240 by -1
influxdb-python fails to build with pandas 2.0, currently in experimental.
Build log:
https://launchpadlibrarian.net/680700174/buildlog_ubuntu-mantic-amd64.influxdb-python_5.3.1-3_BUILDING.txt.gz
A common source of failu
Package: src:jsonpickle
Version: 3.0.0+dfsg1-1
Control: block 1043240 by -1
jsonpickle fails to build with pandas 2.0, currently in experimental.
Build log:
https://launchpadlibrarian.net/680700300/buildlog_ubuntu-mantic-amd64.jsonpickle_3.0.0+dfsg1-1_BUILDING.txt.gz
Autopkgtest log:
https://ci
Package: src:python-biom-format
Version: 2.1.12-3build1
Control: block 1043240 by -1
python-biom-format fails to build with pandas 2.0, currently in
experimental.
Build log:
https://launchpadlibrarian.net/680701317/buildlog_ubuntu-mantic-amd64.python-biom-format_2.1.12-3build1_BUILDING.txt.gz
Package: src:python-altair
Version: 4.2.0-1
Control: block 1043240 by -1
python-altair fails to build with pandas 2.0, currently in experimental.
Build log:
https://launchpadlibrarian.net/680701318/buildlog_ubuntu-mantic-amd64.python-altair_4.2.0-1_BUILDING.txt.gz
A common source of failures is
Package: src:python-anndata
Version: 0.8.0-4
Control: block 1043240 by -1
python-anndata fails to build with pandas 2.0, currently in experimental.
Build log:
https://launchpadlibrarian.net/680701368/buildlog_ubuntu-mantic-amd64.python-anndata_0.8.0-4_BUILDING.txt.gz
Autopkgtest log:
https://ci
Package: src:python-feather-format
Version: 0.3.1+dfsg1-6build1
Control: block 1043240 by -1
python-feather-format fails to build with pandas 2.0, currently in
experimental.
Build log:
https://launchpadlibrarian.net/680701469/buildlog_ubuntu-mantic-amd64.python-feather-format_0.3.1+dfsg1-6buil
Package: src:python-pauvre
Version: 0.2.3-2
Control: block 1043240 by -1
python-pauvre fails to build with pandas 2.0, currently in experimental.
https://launchpad.net/~rebecca-palmer/+archive/ubuntu/pandas2p0/+build/26483328
(I don't know why the build log is missing.)
A common source of failu
Package: src:python-upsetplot
Version: 0.8.0-1
Control: block 1043240 by -1
python-upsetplot fails to build with pandas 2.0, currently in experimental.
Build log:
https://launchpadlibrarian.net/680701778/buildlog_ubuntu-mantic-amd64.python-upsetplot_0.8.0-1_BUILDING.txt.gz
Autopkgtest log:
http
Package: src:q2templates
Version: 2022.11.1+ds-2
Control: block 1043240 by -1
q2templates fails to build with pandas 2.0, currently in experimental.
Build log:
https://launchpadlibrarian.net/680701792/buildlog_ubuntu-mantic-amd64.q2templates_2022.11.1+ds-2_BUILDING.txt.gz
Autopkgtest log:
https
Package: src:sklearn-pandas
Version: 2.2.0-1.1
Control: block 1043240 by -1
sklearn-pandas fails to build with pandas 2.0, currently in experimental.
Build log:
https://launchpadlibrarian.net/680702008/buildlog_ubuntu-mantic-amd64.sklearn-pandas_2.2.0-1.1_BUILDING.txt.gz
A common source of fail
Package: src:python-pyani
Version: 0.2.12-2
Control: block 1043240 by -1
python-pyani fails to build with pandas 2.0, currently in experimental.
Build log:
https://launchpadlibrarian.net/680702373/buildlog_ubuntu-mantic-amd64.python-pyani_0.2.12-2_BUILDING.txt.gz
Autopkgtest log:
https://ci.deb
Package: src:python-skbio
Version: 0.5.8-4
Control: block 1043240 by -1
python-skbio fails to build with pandas 2.0, currently in experimental.
Build log:
https://launchpadlibrarian.net/680702984/buildlog_ubuntu-mantic-amd64.python-skbio_0.5.8-4_BUILDING.txt.gz
Autopkgtest log:
https://ci.debia
Package: src:pyranges
Version: 0.0.111+ds-4
Control: block 1043240 by -1
pyranges fails to build with pandas 2.0, currently in experimental.
Build log:
https://launchpadlibrarian.net/680704234/buildlog_ubuntu-mantic-amd64.pyranges_0.0.111+ds-4_BUILDING.txt.gz
(This isn't just #1042046 - it fail
Package: src:q2-types
Version: 2022.11.1-2
Control: block 1043240 by -1
q2-types fails its autopkgtest with pandas 2.0, currently in experimental.
Log:
https://ci.debian.net/data/autopkgtest/unstable/amd64/q/q2-types/36575888/log.gz
A common source of failures is that pandas.util.testing has be
Package: src:q2-taxa
Version: 2022.11.1+dfsg-2
Control: block 1043240 by -1
q2-taxa fails its autopkgtest with pandas 2.0, currently in experimental.
Log:
https://ci.debian.net/data/autopkgtest/unstable/amd64/q/q2-taxa/36575887/log.gz
A common source of failures is that pandas.util.testing has
Package: src:q2-quality-control
Version: 2022.11.1-2
Control: block 1043240 by -1
q2-quality-control fails its autopkgtest with pandas 2.0, currently in
experimental.
Log:
https://ci.debian.net/data/autopkgtest/unstable/amd64/q/q2-quality-control/36575885/log.gz
A common source of failures is
Package: src:q2-demux
Version: 2022.11.1+dfsg-2
Control: block 1043240 by -1
q2-demux fails its autopkgtest with pandas 2.0, currently in experimental.
Log:
https://ci.debian.net/data/autopkgtest/unstable/amd64/q/q2-demux/36575881/log.gz
A common source of failures is that pandas.util.testing h
Package: src:q2-cutadapt
Version: 2022.11.1-2
Control: block 1043240 by -1
q2-cutadapt fails its autopkgtest with pandas 2.0, currently in
experimental.
Log:
https://ci.debian.net/data/autopkgtest/unstable/amd64/q/q2-cutadapt/36575880/log.gz
A common source of failures is that pandas.util.tes
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 pandas.util
Package: src:python-nanoget
Version: 1.16.1-2
Control: block 1043240 by -1
python-nanoget fails its autopkgtest with pandas 2.0, currently in
experimental.
Log:
https://ci.debian.net/data/autopkgtest/unstable/amd64/p/python-nanoget/36575861/log.gz
A common source of failures is that pandas.ut
Package: src:mirtop
Version: 0.4.25-3
Control: block 1043240 by -1
mirtop fails its autopkgtest with pandas 2.0, currently in experimental.
Log:
https://ci.debian.net/data/autopkgtest/unstable/amd64/m/mirtop/36575823/log.gz
A common source of failures is that pandas.util.testing has been rename
Package: src:dyda
Version: 1.41.1-1.1
Control: block 1043240 by -1
dyda fails its autopkgtest with pandas 2.0, currently in experimental.
Log:
https://ci.debian.net/data/autopkgtest/unstable/amd64/d/dyda/36575804/log.gz
A common source of failures is that pandas.util.testing has been renamed
t
Package: src:xarray-sentinel
Version: 0.9.5+ds-1
Control: block 1043240 by -1
xarray-sentinel fails to build with pandas 2.0, currently in experimental.
Build log:
https://launchpad.net/~rebecca-palmer/+archive/ubuntu/pandas2p0/+build/26483387/+files/buildlog_ubuntu-mantic-amd64.xarray-sentinel_
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 ren
Package: src:intake
Version: 0.6.6-1
Control: block 1043240 by -1
intake fails to build with pandas 2.0, currently in experimental.
Build log:
https://launchpad.net/~rebecca-palmer/+archive/ubuntu/pandas2p0/+build/26483259/+files/buildlog_ubuntu-mantic-amd64.intake_0.6.6-1_BUILDING.txt.gz
A com
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 bee
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 python-p
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.
Ups
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.)
Package: python3-dask
Version: 2022.12.1+dfsg-2
Tags: fixed-upstream
pandas 2.0's test_dask fails (in Salsa CI). Upstream reports suggest
that this is fixed in dask 2023.2, but I haven't checked whether
upgrading dask breaks anything else.
https://github.com/dask/dask/issues/10164
(I also co
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 buil
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 remo
Control: reopen -1
Please also remove theano from experimental.
Control: retitle -1 RM: theano -- RoM; broken, mostly abandoned
On 31/07/2023 13:49, Andrius Merkys wrote:
Maybe it is worth to keep src:keras for the time
being, until keras 3 arrives?
Similar things have happened before - src:llvm-toolchain-9 was removed
well before src:beignet, making src:
Package: ftp.debian.org
User: ftp.debian@packages.debian.org
Usertags: remove
Control: affects -1 src:theano src:deepnano src:keras
Control: reopen 1026539
Control: reopen 1027215
theano has been mostly abandoned upstream since 2018. (The Aesara fork
is not abandoned, but includes interface
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:
https://github.com/pandas-dev/pandas/commit/ce9e3d658d6efa3600a4563ca7a00e7a15b8
sorry, discussion on pkg-opencl-devel / debian-devel around 19 June, not
actually in #974792
Package: ftp.debian.org
beignet FTBFS with LLVM > 9 (#974792), and hence cannot be built in
current unstable. (The existing package probably still works, because
beignet statically links LLVM to avoid #852746, but unbuildable packages
are unreleasable by policy.)
beignet is abandoned upstre
Package: hyperspy
Version: 1.7.3-1
Severity: serious
hyperspy currently FTBFS with several failing tests:
https://launchpadlibrarian.net/678551154/buildlog_ubuntu-mantic-amd64.hyperspy_1.7.3-1_BUILDING.txt.gz
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 te
Additional information:
As a rough estimate of how much speed this would cost on older hardware,
I previously measured beignet as 8-16x faster than pocl (but this will
obviously depend on hardware and application). However, beignet (on
hardware that can't use intel-opencl-icd) is limited to s
beignet FTBFS with LLVM > 9 (#974792). beignet uses libllvm/libclang
heavily enough that it usually has this kind of bug on a new LLVM
release, but this time my attempts to fix it failed (see the Salsa CI logs).
It is abandoned upstream and mostly replaced by intel-opencl-icd. (This
is not a
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.
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?
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 that
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 cha
I don't consider the lack of .xls in pandas worth a freeze exception,
but consider it reasonable for others to disagree with that.
As noted in the bug, there are some (possibly not-technically-valid)
.xlsx files that xlrd 1 can open but openpyxl can't - _pandas_ won't be
able to open those eit
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 up
Package: python3-optuna
Severity: serious
Control: affects -1 python3-pandas
test_create_new_trial (both parts) sometimes fails on s390x, failing the
autopkgtest.
It might make sense to remove this package on s390x, if it isn't
reasonable to actually fix this.
Package: python3-pymatgen
Severity: serious
Control: affects -1 python3-pandas
The autopkgtest sometimes times out, and when it does, the last line is
io/tests/test_babel.py and 6 'pass' dots, implying that the 7th item hung.
All known instances are on amd64.
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 Recomm
Possibly useful here: gdb disassemble works inside pocl kernels, see
#920497 for an example.
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.
On 10/02/2023 06:41, Andreas Tille wrote:
Am Fri, Feb 10, 2023 at 08:44:01AM +0530 schrieb Nilesh Patra:
But I am not sure if this counter would be set to 2 days (from 5 days)
or not -- will likely need to ask release team.
As far as I observed the migration time is now 5 days (no matter wheth
Upstream's reason for treating warnings as errors is just generic 'find
potential problems' (https://github.com/dask/distributed/issues/6048).
On 09/02/2023 21:33, Diane Trout wrote:
That worked, but armel (test_steal_twice), armhf (something outright
crashing) and s390x (lots) all failed.
Ar
On 09/02/2023 21:33, Diane Trout wrote:
The place to ask is debian-release; no comment on the likely result.
I'll try to ask.
Looking at the old logs, I think the old "passing" test *didn't actually
run* the tests (just collected them, which was enough to fail on a
dask/dask.distributed mi
On 09/02/2023 17:07, Diane Trout wrote:
Would it make sense to drop those errors back to warnings, and do you
know enough about the setup.cfg language to do it quickly?
Plausibly yes but I don't actually know, and remove the 'error' line at
setup.cfg:60.
I went ahead and requested anoth
On 09/02/2023 06:36, Diane Trout wrote:
Also there's still some flaky tests as the rebuild triggered by my just
committing the changelog release had a failure in "test_release_retry"
I don't think I've seen that particular one before, though like several
others it's a warning being treated as
On 08/02/2023 22:09, Diane Trout wrote:
I just got back a passed from salsa. So does anyone want to make any
more changes? Or should we release this version?
The *maybe* remaining issue is that test_balance_expensive_tasks[enough
work to steal] seems to fail repeatedly when it fails, so if we wa
I think I got the code to detect if IPv6 is available to work correctly
so I could set the DISABLE_IPV6 environment variable that
dask.distrubted supports.
This probably refers to
https://salsa.debian.org/python-team/packages/dask.distributed/-/blob/debian/master/debian/tests/run-tests#L11
T
On 07/02/2023 03:20, Diane Trout wrote:
What's your test environment like?
Salsa CI.
I don't think head is hugely different from what was released in -1.
The diff looks like Andreas adjusted the dask dependency version,
configured a salsa CI run, and added some upstream metadata files
That
I agree that xfailing the tests *may* be a reasonable solution. I'm
only saying that it should be done by someone with more idea than me of
whether these particular tests are important, because blindly xfailing
everything that fails is effectively not having tests.
If we do choose that approa
(Background: the pandas + dask transition broke dask.distributed and it
was hence removed from testing; I didn't notice at the time that if we
don't get it back in we lose Spyder.)
On 05/02/2023 21:44, Rebecca N. Palmer wrote:
I currently have this in a state where it sometimes su
I currently have this in a state where it sometimes succeeds and
sometimes doesn't:
https://salsa.debian.org/rnpalmer-guest/dask.distributed/-/tree/fix1030096
Tests I've seen to fail multiple times (and don't have a fix for):
test_balance_expensive_tasks[enough work to steal]
https://salsa.debia
That removed most of the test failures, but there seem to be a few
apparently random ones left (2 runs both failed, but with different errors).
On 04/02/2023 21:35, Andreas Tille wrote:
Any reason to not push to master directly?
I don't do that with packages that aren't mine. Also see above.
101 - 200 of 922 matches
Mail list logo
