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.
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.
Package: astro-python3
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 exac
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: 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 we'
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 togeth
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 #1004
Package: python3-dipy
Version: 1.5.0-6
Tags: patch
test_mapmri_isotropic_static_scale_factor measures wall-clock time to
check which of two methods is faster, which is flaky on a shared
autopkgtest server. (Known instances of it failing are
https://ci.debian.net/data/autopkgtest/testing/amd64
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 setup.py/requirem
Control: tags -1 fixed-upstream patch
Control: forwarded -1 https://github.com/scipy/scipy/pull/17033
This "broken by numpy 1.24" bug looks to me like 17033, not 17630. This
has what looks like a trivially-backportable patch, though I haven't
actually tried that:
https://github.com/scipy/scip
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 othe
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 currently
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.
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} ha
(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 12th
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.
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.
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
dask.distribu
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), but
Control: tags -1 fixed-upstream
Those are all from bcolz, which upstream dask has stopped using:
https://github.com/dask/dask/pull/9479
(Upstream also mention numpy 1.24 in
https://github.com/dask/dask/pull/9777
which hasn't been in a release yet, but that one looks like it's only
suppressing w
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 2022-11-13)
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.
Package: python3-dask
Version: 2022.02.0+dfsg-2
Tags: fixed-upstream
Control: block 1022571 by -1
With pandas 1.5 (currently in experimental), the dask autopkgtest fails:
https://ci.debian.net/data/autopkgtest/unstable/amd64/d/dask/28842796/log.gz
This appears to be fixed upstream, but I haven't
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
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 (and
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.) statsmodel
Control: block 1022571 by -1
This still fails with pandas 1.5.
Build log:
https://launchpadlibrarian.net/633830773/buildlog_ubuntu-lunar-amd64.python-skbio_0.5.6-6build2_BUILDING.txt.gz
Autopkgtest log:
https://ci.debian.net/data/autopkgtest/unstable/amd64/p/python-skbio/28542505/log.gz
Package: q2templates
Version: 2022.8.0+ds-1
Control: block 1022571 by -1
Tests fail with pandas 1.5 (currently in experimental).
Build log:
https://launchpadlibrarian.net/633830688/buildlog_ubuntu-lunar-amd64.q2templates_2022.8.0+ds-1_BUILDING.txt.gz
Autopkgtest log:
https://ci.debian.net/data/a
Package: python3-emperor
Version: 1.0.3+ds-4
Control: block 1022571 by -1
Tests fail with pandas 1.5 (currently in experimental).
Build log:
https://launchpadlibrarian.net/633828020/buildlog_ubuntu-lunar-amd64.emperor_1.0.3+ds-4_BUILDING.txt.gz
Autopkgtest log:
https://ci.debian.net/data/autopkg
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
ex
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 test_nul
Package: python3-parso
Version: 0.8.1-1
Tags: fixed-upstream
Control: block 1023965 1021984 by -1
Attempting to use parso on Python 3.11 gives an error that this is not
supported.
(e.g. some pandas tests do this -
https://launchpadlibrarian.net/631797785/buildlog_ubuntu-lunar-amd64.pandas_1.3
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 only,
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 b
Source: pocl
Version: 1.8-1
(Filing this as something to refer to when I disable those tests; it may
or may not actually be worth fixing.)
Since some time in August, all the packages that use pocl for their
autopkgtests have been failing on armel/armhf (but not arm64) with either
Assertion `
Control: tags -1 patch
This looks similar to #997026, and the same fix appears to work.
Reproduced here; not obviously known upstream. Autopkgtest says it
started between 2021-08-30 and 2021-09-14 in unstable, between
2021-10-10 and 2021-10-18 in testing.
It might be easiest to upgrade to 0.13.0 (if it fixes this - I haven't
checked yet), given that we should do that anyway at s
On 15/10/2021 14:46, Andreas Tille wrote:
Hi Rebecca
and whoever might care. As usual snakemake is troublesome to upgrade.
I have injected the latest version into Git but there are lots of
failed tests. It would be great if someone could care about this.
Kind regards
Andreas.
I had
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Severity: normal
theano 1.0.5+dfsg-3 is currently held in unstable for an autopkgtest
"regression" on armhf.
The test in question (smoketestgpu) is currently skipped in plain
testing because it depends
I'm not aware of a fix for this, and beignet is abandoned upstream and
mostly useful for old hardware (on newer hardware it is replaced by
intel-opencl-icd). However, I may look at it more later (and at least
try llvm-toolchain-12, though I'd expect that to be worse if anything).
Hence, I'm f
On 22/09/2021 07:32, Andreas Beckmann wrote:
We will proably still run into problems if different ICDs built against
different LLVM versions are going to be loaded at the same time (e.g.
pocl/llvm9 and intel/llvm1x) because the different llvm versions seem to
stomp on each others internal bits.
There's also this test failure on arm64 (which is at least a crash not a
wrong answer), again with clblast not clblas. It probably isn't a new
problem either: the tests were previously run with clblas only.
(The "regression" on ppc64el is that the test has never been installable
there and we'
Control: retitle -1 libgpuarray: *gemv broken on libclblast
For now I have disabled *gemv when used with libclblast, to make this
bug an explicit error rather than a silently wrong answer.
These functions are still available with clblas, but that has enough
other issues (https://bugs.debian.o
Control: tags -1 pending
This is the same underlying problem as #992673, but for this one it
looks like switching to clblast is enough to pass the tests we actually
run. (Which isn't all of them because the GPU part of theano has never
fully worked under OpenCL, but we already warn the user a
clblas has been replaced by clblast, so I tried switching to that, but
doing so makes a varying number of cases of test_gemv fail, e.g.
==
FAIL: pygpu.tests.test_blas.test_gemv((128, 50), 'float32', 'c', True,
False, 2, True, F
Control: reassign -1 src:statsmodels
Control: tags -1 fixed-upstream
Appears to be these (but not yet tested in Debian):
https://github.com/statsmodels/statsmodels/issues/7371
https://github.com/statsmodels/statsmodels/issues/7453
This is _probably_ the same issue that 0.23.3+dfsg-3 has had since it
was new: some tests run in all installed locales, and on
reproducible-builds (but not buildds without a locales-all dependency)
this includes a few with no text encoding.
The underlying issue is in Python stdlib, and is an e
Fine by me, thanks.
What, if any, action are you proposing before bullseye? Or is this a
request for an up-to-date pandas in experimental?
That workaround just disables the affected test, i.e. it will probably
fix the FTBFS but do nothing to the underlying problem. As noted in
#983404, a real scipy fix also exi
On 22/02/2021 12:44, Drew Parsons wrote:
v1.2.2 is the latest pandas release
Has this error in test_from_coo been fixed in that latest release?
Not obviously, but I haven't tried actually running that.
Is scipy 1.6.1 intended for bullseye?
On 17/02/2021 10:00, Andreas Beckmann wrote:
Note to self: `reportbug clinfo` should report all installed ICDs
Feel free to borrow beignet-opencl-icd.bug-script
Control: tags -1 fixed-upstream pending
The trigger was a change in the outside world, not Debian testing: the
tests (of HTML table parsing) were trying to access a web page that no
longer exists. Fixed in Salsa.
Package: www.debian.org
On the packages.d.o pages of arch:all packages from sid, bullseye or
experimental, the "list of files" link gives the error message "No such
package in this suite on this architecture."
This does not affect arch:any packages, or packages from stable.
e.g.
fails - http
Control: retitle -1 RM: hyantesite -- RoM; behaviour does not match
documentation, upstream/uploader inactive
The patches above and regenerating the test references would probably
fix the FTBFS, but that still leaves the code for amortized_disk and
pareto not matching the documentation. It wou
I have applied this workaround to pandas. However, this only makes
pandas use xlrd less; this bug still exists in other users of xlrd when
defusedxml is installed. By default this includes python3-glue (the
original reason for upgrading xlrd), via the Recommends/Depends chain
python3-glue ->
Control: severity -1 serious
Control: affects -1 pandas
This breaks the default form of pandas.read_excel().
A workaround for this is to use pandas.read_excel(engine='openpyxl'),
and pandas upstream have made this the default:
https://github.com/pandas-dev/pandas/pull/35029/files
I intend to
On 05/12/20 at 13:47 +0100, Lucas Nussbaum wrote:
Tags: bullseye sid ftbfs
Usertags: ftbfs-20201205 ftbfs-bullseye
Does this imply that it was also tested and failed in bullseye? The log
is marked unstable, and the test failures in it are #976620, which is
probably unstable-only.
Package: python3-xlrd
Version: 1.2.0-1
Tags: patch
xlrd 1.2.0 started using defusedxml if available.
As defusedxml.cElementTree does not have a top-level ElementTree
attribute, Element_has_iter gets set to False
(https://sources.debian.org/src/python-xlrd/1.2.0-1/xlrd/xlsx.py/#L59).
However,
Existing discussion (in what was originally a different bug):
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974797#28
This bug might also be in llvm or clblas.
(libgpuarray maintainer)
This isn't testable in a qemu-armhf chroot, as pocl doesn't work there.
Do all the non-clblas tests pass? (This can be checked by uninstalling
libclblas-dev then running the tests - this will "error" the clblas
tests but should at least not crash them.)
On 19/11/202
https://lists.freedesktop.org/archives/beignet/2020-January/009251.html
With that partial patch, the errors are
LLVM 10:
builtin_acos_float()clang (LLVM option parsing): for the
--pgo-warn-misexpect option: may only occur zero or one times!
LLVM 11:
In file included from
/build/beignet-1.3.2
Control: severity -1 minor
Control: retitle -1 imperfect/non-upstreamable architecture detection
The sys.maxsize check should catch amd64 vs i386; the directory check is
mostly to catch other-32-bit vs i386. All this patch does is allow more
rounding error in some tests (because i386 registers
Control: tags -1 upstream
cfgrib's upstream CI is failing, and started failing when it started
using pandas 1.1.x.
Confirmed, still exists in pandas 1.1.4, not obviously known upstream.
#969648 was also a datetime issue that appeared during the pandas 1.0 ->
1.1 transition, but I don't know if they're related. (cfgrib wasn't
tested as part of that transition because it doesn't directly depend on
pandas.)
Control: affects -1 + pynpoint python-loompy umap-learn
Control: affects -1 + dolfinx python-numpy-groupies
As this bug cannot immediately be fixed, numba may be removed from
testing to unblock the python3.9 transition (#966426).
(If any of the failed tests are silently wrong answers, please d
A bot wrote:
Dependency installability problem for dask on all:
dask build-depends on:
- python3-pandas:amd64 (>= 0.19.0)
dask build-depends on:
- python3-distributed:amd64
python3-distributed depends on:
- python3-dask:amd64 (>= 2.9.0)
python3-pandas conflicts with:
- python3-dask:amd64 (< 2.11
On 19/10/2020 20:07, Stefano Rivera wrote:
Hi Rebecca (2020.10.19_11:51:33_-0700)
Or maybe not an actual regression...it's a ~5e-7 difference and one of the
things the patch does (at around dask/dataframe/tests/test_rolling.py:270)
is _tighten_ the tolerance on that test.
Hrm, I didn't see th
Or maybe not an actual regression...it's a ~5e-7 difference and one of
the things the patch does (at around
dask/dataframe/tests/test_rolling.py:270) is _tighten_ the tolerance on
that test.
I have filed a separate bug (#972516) for the fsspec issues.
Package: python3-dask
Version: 2.11.0+dfsg-1
Some of fsspec's functionality now requires python3-aiohttp, including
parts used in dask autopkgtests:
https://ci.debian.net/data/autopkgtest/testing/amd64/d/dask/7549002/log.gz
Some of these work if I add a test-dependency, but 2 continue to fail
ertionError
diff -Nru dask-2.11.0+dfsg/debian/changelog dask-2.11.0+dfsg/debian/changelog
--- dask-2.11.0+dfsg/debian/changelog 2020-02-26 21:01:52.0 +
+++ dask-2.11.0+dfsg/debian/changelog 2020-10-19 08:38:20.0 +0100
@@ -1,3 +1,10 @@
+dask (2.11.0+dfsg-1.1) UNRELEASED; urgency=me
The upstream patch doesn't even apply as-is; this version does, but I
don't have time right now to actually test it.
There's also a circular dependency problem, as dask indirectly
build-depends on itself and my new pandas makes it uninstallable.
Description: pandas 1.1 compatibility
Origin:
Package: python3-joblib
Tags: fixed-upstream
Control: affects -1 scikit-learn statsmodels
Control: block 966426 by -1
Severity: serious
Justification: causes other packages to FTBFS
Our current version of joblib is incompatible with Python 3.9, which was
recently added to the supported versions
Control: tags -1 pending
Control: forwarded -1 https://github.com/pandas-dev/pandas/issues/37217
This appears to fix it, though I'm not yet sure if it's a good idea
I was trying to find upstream's fix and use that instead, but it now
looks like they don't have one, and probably didn't know th
Control: tags -1 patch
The underlying cause (and reason this is 3.9-specific) appears to be the
mostly-removal of ast.Index and its replacement by a bare value.
This appears to fix it, though I'm not yet sure if it's a good idea:
--- a/pandas/core/computation/pytables.py
+++ b/pandas/core/com
This bug is not specific to DateTimeIndexes, and the immediate cause is
the index being passed to numpy as a
pandas.core.computation.pytables.Constant instead of an int:
$ python3.9
Python 3.9.0+ (default, Oct 16 2020, 17:57:59)
[GCC 10.2.0] on linux
Type "help", "copyright", "credits" or "lice
The error message has gone for me as well, but I don't have the hardware
to tell whether mesa-opencl-icd actually works. Have you checked this?
I agree that this is probably the same bug as #964973, which is marked
as fixed.
Control: tags -1 - pending
The package currently in Salsa doesn't work. test_statsmodels is
probably a circular dependency that should be ignored for now;
TestHDFStore is under investigation.
=== FAILURES
===
T
Control: severity 969648 serious
Control: tags 969650 pending
Control: tags 972033 pending
Python 3.9 related breakage has been declared RC, so if nobody objects,
I intend to upload pandas 1.1 to unstable (possibly tonight, but it
probably won't build before numpy and matplotlib are binNMUd fo
The linked upstream report says this went away in numpy 1.18.4, and the
tests in question now pass on debci.
Control: block 972033 by 969650
This is now the only bug blocking pandas 1.1. Is there something wrong
with the above fix, or have you just not had time to try it?
Upgrading dask to a newer upstream version is also an option, but I
haven't checked if it would break anything else.
Python 3.
There's a 1.1.3 package in Salsa, but it hasn't been tested. (With
python3-all-dev from experimental, it fails because numpy doesn't have a
3.9 build yet.)
Control: merge -1 972015
Control: found -1 1.0.5+dfsg-3
Control: forwarded -1 https://github.com/pandas-dev/pandas/issues/36296
Control: tags -1 fixed-upstream
pandas 1.1.3 may fix this, but moving to 1.1.x triggers #969648.
Most of these tests no longer fail in 0.11.1-5 (current Ubuntu) and
0.12.0-2 (current Debian), but 3 still do: two variants of varmax
test_bse_oim, and test_pickle_fit_sarimax.
Control: affects -1 snakemake
Upstream snakemake have now moved to pulp 2.x - but went straight from
1.x only to 2.x only, i.e. they need to be upgraded together.
Jessica Clarke wrote:
It seems to me like dpkg has done a very dodgy
sequence of events that have resulted in the system being broken for a
short period and, whilst most don't notice, cowdancer does. Why is this
not a dpkg (or apt) bug? It should be possible to do that sequence in a
way that pres
This _might_ be an API break. The reverse dependencies are snakemake
and congress.
snakemake recently started declaring a <=1.6.8 version restriction:
https://github.com/snakemake/snakemake/commits/a7ac40c96d6e2af47102563d0478a2220e2a2ab7
However, their reason seems to be that pulp 2.x doesn't
Control: severity -1 important
Control: retitle -1 statsmodels: on armel may give wrong answer or crash
This bug is no longer an FTBFS as the tests are now ignored on armel,
but still exists. (At least as a crash; we stopped using --forked, so
don't know if there are still also wrong answers.)
Package: python3-pandas
Version: 1.0.5+dfsg-3
Severity: wishlist
Control: block -1 by 969648 969649
pandas 1.1.x is currently in experimental. The upstream description
suggests this is not supposed to be an API break, but does have new
warnings.
Packages tested with it (build + autopkgtest):
Package: python3-skbio
Version: 0.5.6-2
With pandas 1.1 from experimental, python-skbio fails 3 of its tests.
Log:
https://ci.debian.net/data/autopkgtest/unstable/amd64/p/python-skbio/6900486/log.gz
Package: python3-dask
Version: 2.11.0+dfsg-1
Tags: fixed-upstream
With pandas 1.1.x from experimental, dask fails 8 of its tests, at least
mostly datetime-related.
Log:
https://ci.debian.net/data/autopkgtest/unstable/amd64/d/dask/6900447/log.gz
Upstream fix (untested): https://github.com/da
Control: reopen -1
Looks like pytest --forked --runxfail doesn't work properly (probably
related to
https://github.com/pytest-dev/pytest-forked/pull/34#discussion_r436140456),
so that wasn't a valid test.
This bug can happen even if the tests being run don't actually use
pytest_asyncio (e.g. see pandas 1.0.5+dfsg-2); to avoid it one needs to
not have it installed, i.e. remove the build/test-dependency.
This suggests that the current pytest-asyncio package is totally
unusable without a more rece
201 - 300 of 922 matches
Mail list logo
