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.
Probably fixed - see my merge request on Salsa.
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
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
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
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-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.
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
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
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.
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
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.
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]
(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 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
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
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
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 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 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
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 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
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.
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 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
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 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
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
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
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
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: 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
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
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
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,
Control: tags -1 pending
This appears to be fixed in Salsa (before I reported it) - is there any
reason not to upload this now?
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:
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.)
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.)
This has been merged but not uploaded - is there a reason it shouldn't
be, or have you just not had time?
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:
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: 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
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: 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.
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
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
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
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
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
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
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.
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
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*
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
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
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
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.
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.
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
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
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/
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
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: 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
Thanks - I plan to look at this tomorrow.
The initial error appears to be "SQLite objects created in a thread can
only be used in that same thread." with a traceback pointing to
pytools/persistent_dict.py, and the timing matches pytools 2024.1.1 ->
2024.1.6.
I intend to look into this more later.
Control: retitle -1 pytools.persistent_dict fails in multithread
Control: reassign -1 python3-pytools
Control: affects -1 snakemake
Control: tags -1 fixed-upstream
Control: severity -1 normal
(for pytools - it's still RC for snakemake)
This was probably introduced when pytools.persistent_dict
301 - 379 of 379 matches
Mail list logo
