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/
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
Thanks - I plan to look at this tomorrow.
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
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.)
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: tag -1 pending
Hello,
Bug #1061761 in snakemake reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
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:
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
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.
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
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
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: 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
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
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
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
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,
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'
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.)
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:
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
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
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
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 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
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.
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
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.
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
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
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
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
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
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
(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 succeeds
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]
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
I have an attempt to fix this in Salsa now (in my fork), but it hasn't
had time to run the tests yet, so I don't know whether it works.
Note the above mention that if we lose dask.distributed then we lose
Spyder, which makes this a bigger issue than I initially thought.
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.
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.
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
Control: tags -1 pending
Looks like rounding error in a test; ignored in Salsa.
Would you like some help? If so, please push what you currently have to
Salsa so we can see it.
(No promises - #1029251 doesn't look like a big job but I might be wrong
about that.)
Package: python3-distributed
Version: 2022.02.0+ds1-3
Severity: serious
dask.distributed has been failing its autopkgtests since dask was
upgraded to 2022.12.1.
This is the expected result of upgrading one but not the other: I'd seen
the same in my test PPA, and the upstream
On 16/01/2023 07:22, Diane Trout wrote:
On Sun, 2023-01-15 at 14:42 -0800, Diane Trout wrote:
On Sun, 2023-01-15 at 18:16 +, Rebecca N. Palmer wrote:
Probably fixed - see my merge request on Salsa.
I'd tried to build versions of dask from 2022.03 - 2022.06 and they
all
failed
Probably fixed - see my merge request on Salsa.
Control: retitle -1 dask: B-D on python-numpy-doc which no longer exists
Control: tags -1 pending
The python-numpy-doc error is because that package no longer exists.
This build-dependency has already been removed in Salsa.
However, that version doesn't build the dask documentation due to
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
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.
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}
(I meant to send that to the dask/pandas bug, which is #1025393, but
both of them are potential reasons to update dask.)
The intake issue is now https://github.com/dask/dask/issues/9813
(They're planning to fix it in intake rather than dask, but we might not
be allowed to do that after the
To get the new upstream version to work, dask_sphinx-theme, dask and
dask.distributed all need to be updated, in that order. Tests here:
https://launchpad.net/~rebecca-palmer/+archive/ubuntu/dask2022p12v2/+packages
dask didn't run its tests (PPAs only build, not autopkgtest), and
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.
This combination stopped failing on 2022-11-22/23 (without a dask
upload, suggesting it was fixed somewhere other than dask itself).
Hence, I suggest closing this bug.
Control: severity -1 grave
Control: merge -1 1024795
Control: retitle -1 llvmlite: uninstallable due to llvm-11 removal
It looks like closing and reopening this removed its "blocks"
relationship to 1000941 (the llvm-11 removal request). Hence, llvm-11
has now been removed, making llvmlite
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
Control: block 1021984 by -1
Control: tags -1 fixed-upstream fixed-in-experimental
There's more than just those 2[0].
Some are tests that expect an error and check the message (not just the
type), and fail because the message has been reworded - these should be
trivial to fix.
The 2 in
This is the same test as #1014278 / upstream 8341, but now on amd64.
From the upstream discussion, it may be a numerically unstable test.
It doesn't fail everywhere: a test build on Salsa CI passed, as did the
last debci runs. (reproducible-builds FTBFS on the second build, on
amd64/sid
Control: tags -1 pending
(fixed in Salsa, as far as I consider it my bug)
It looks like both of these originate further down the stack, not in
libgpuarray:
The *ger error code is an OpenCL compile failure from inside clblast, so
likely either pocl or clblast.
The *gemv problem appears to
1 - 100 of 377 matches
Mail list logo
