Do you know how to test that ? besides building beignet?
No, sorry - oclgrind is the other package to ship what appear to be
clang .pch files, but I haven't specifically checked whether it's affected.
beignet currently isn't the easiest test case, as (as noted above) it
has other reproducibi
I am able to reproduce this by just compiling (and not running) that on
its own (as below, with the affected source in bug913141kernel.cl).
Hence, no further action is needed from you.
Switching to LLVM 7 (after fixing the other issue you noted) didn't
change anything. Removing -cl-fast-relax
On 10/11/2018 14:53, Rebecca N. Palmer wrote:
I had been mostly ignoring those because there was no point fixing them
if this bug was to be left open, but can try to deal with them today.
salsa beignet now has a fix for the INPUT_FILES_BLOCK issue (and uses
LLVM 7), so applying this patch to
Package: apparmor-profiles
Version: 2.13-8
Control: tags -1 patch
Control: affects -1 src:firefox src:firefox-esr
Firefox now uses /dev/shm in its multiprocess sandboxing. If AppArmor
blocks this (I was using a custom profile, but the packaged profile
appears to have the same problem), the Fir
This also happens on amd64 (backtrace follows), where it only affects
python3.7-dbg (not python3-dbg (3.6) or python3.7). It happens on
interpreter exit, not on import.
I suspect this is _not_ the new cffi version as such, because:
- It does not affect pyzmq or pillow (which also use cffi and
Package: autopkgtest
Version: 5.5
When a new version of the package under test enters the archive during a
test run, the tests towards the end of the run may use the binaries of
the new version, but debci lists it as a test of the old version.
If these tests fail because the new version conta
On 23/09/2018 18:04, Paul Gevers wrote:
I didn't came across it yet.
Probably because it's so rare, and easy not to notice if the status
didn't change.
What kind of logic do you have in mind?
If any binary of the package under test is being installed and isn't the
same version as the sou
On 23/09/2018 19:51, Paul Gevers wrote:
Hi,
On 23-09-18 19:29, Rebecca N. Palmer wrote:
What kind of logic do you have in mind?
If any binary of the package under test is being installed and isn't the
same version as the source, abort the run as a tmpfail. (At least in a
standard debc
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
(or should this be 'nmu'?)
The Clang resource directory (clang --print-resource-dir) changes every
upstream *bugfix* release (e.g. /usr/lib/llvm-6.0/lib/clang/6.0.1/ ),
but clang's rev
Control: unblock -1 by 873408
Control: block 893401 by 873408
(julia has now moved to LLVM 4.0)
beignet, and presumably mesa, use LLVM 3.8 on kfreebsd-* because there
isn't anything newer available there.
LLVM 3.9 to 6.0~svn315736 were attempted and FTBFS on kfreebsd-*; these
bugs do not appe
Package: g++-9
Version: 9.2.1-23
Control: affects -1 src:beignet
Trying to build beignet with llvm 10 and the default -std fails with
this internal compiler error. (See attached for exact changes; it
previously used -std=c++0x, but that fails with LLVM 10 because it can't
find std::index_sequ
Control: retitle -1 g++: ICE at cp/pt.c:15779 on beignet in -std=gnu++14
or higher
This also happens with LLVM 9 (which makes sense given that the error
message points to code in beignet itself):
LLVM 9LLVM 10
-std=c++0x successstd::index_sequence fail
-std
creduce output (and yes, this isn't a valid program, but it still
shouldn't ICE):
template struct a {
enum { b };
};
class c;
template class __attribute__((aligned((a::b d {};
class : d<0> {
Source: libffi
Version: 3.3-3
Severity: serious
(This is a "block migration while I investigate" bug:
it may well be downgraded or reassigned when I know more.)
https://ci.debian.net/packages/libg/libgpuarray/unstable/amd64/
libffi is one of the few that changed:
https://ci.debian.net/data/packa
Paul Gevers wrote:
Unfortunately, old data on ci.d.n is flushed (too much disk space), so I
need a new incident to properly investigate what is going on, as I
haven't spotted the issue yet in the code.
libgpuarray #949767, unstable 2020-01-24:
https://ci.debian.net/packages/libg/libgpuarray/uns
(The above debci log is misleading due to #764081; pocl also changed,
and the failure goes away on using the old pocl.)
It looks like this fails because it is reading the result before the
computation has finished:
- On a failure, the np.asarray(gr) passed to assert_allclose doesn't
match cr (
Control: reassign -1 src:libgpuarray,src:pocl
Control: retitle -1 wrong results in gemm(batch) in out-of-order queues
libgpuarray checks whether the device supports out-of-order queues, and
requests one if it does (src/gpuarray_buffer_opencl.c:155,185).
pocl 1.3 says it doesn't support out-of-
Control: fixed -1 0.25.3+dfsg2-2
Control: tags -1 patch
This is fixed in unstable, and in Salsa's experimental branch. I didn't
consider it worth the buildd resources to upload in experimental,
without also doing some work on other issues such as #877419. (1.0 is
in experimental and not unst
Control: block 962268 by -1
A proposed new package (pymatgen #962268) requires pandas >= 1.0.1.
Current status:
- pandas 1.0.4 is in experimental, and FTBFS on s390x and ppc64el
- psychopy (previously untestable) works
- python-biom-format still fails
- Others have not been retested
The current
On 12/06/2020 14:53, Sébastien Villemot wrote:
I did not investigate whether installing the x13as package is enough to get
support from statsmodels
The documentation implies yes. If you want to check, there are tests
(statsmodels/tsa/tests/test_x13.py), which SKIP if x13as is not found.
Control: retitle -1 test collection crashes/errors out [armel, ppc64el]
The tests now do get run on armhf, but still don't on armel and ppc64el.
This appears to be because some test modules crash/abruptly exit
*during test collection*. (pytest-xdist can start a new worker after a
crash, but
Control: tag -1 - fixed-upstream
Upstream discussion suggests this was fixed ... but then reintroduced in
the move to LLVM 8:
https://github.com/numba/numba/issues/4026
test_array_reshape is still one of the tests that crashes (but a full
test run doesn't even get that far because test_typedl
Numpy 1.19 is currently an ~rc in experimental, and recently became
final upstream.
Both pandas 0.25.x and 1.0.x currently FTBFS with numpy 1.19, but I
think 1.0.x is fixed in Salsa, while 0.25.x looks doable but more work.
(It has a build failure that looks like
https://github.com/pandas-dev
This error occurs when clinfo is run with mesa-opencl-icd installed; it
does _not_ require actual AMD hardware.
Previous similar bugs suggest that compiling libclc/mesa-opencl-icd with
-Bsymbolic, and/or statically linking them to LLVM/Clang, might help:
https://bugs.debian.org/cgi-bin/bugrepo
Control: found -1 0.25.3+dfsg2-3
Control: tags -1 fixed-upstream patch
(untested)
Probably matplotlib 3.3:
https://github.com/pandas-dev/pandas/pull/35323
Control: tags -1 - patch
That's not enough by itself: it does fix that particular error, but
exposes 16 other failures, some of the form
ValueError: The number of FixedLocator locations (8), usually from a
call to set_ticks, does not match the number of ticklabels (4).
and some datetime iss
The patch still works for me (on amd64, dpkg-buildpackage in a chroot
with experimental python3-pandas(-lib), sid everything else; keep the
existing pandas025.patch). Anything obviously different about your test
environment?
Package: python3-pytest-asyncio
Version: 0.14.0-1
Severity: serious
Control: affects -1 src:pandas
pytest-asyncio 0.14 tries to use pytest Function.from_parent (e.g. at
pytest_asyncio/plugin.py:39), which does not exist in the archive's
current version of pytest (4.6). This causes at least pan
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
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.
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
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-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):
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.)
Control: reassign -1 src:sphinx
Control: retitle -1 sphinx breaks python3-breathe < 4.15
Control: tags -1 patch
This does not happen with breathe 4.19 (from experimental); this
upstream report suggests it happens with breathe < 4.15.
https://github.com/sphinx-doc/sphinx/issues/7424
Hence, a f
This looks like #963653, which is fixed by using python3-breathe 4.19
from experimental. However, doing that here gives a different error:
sphinx-build -b html -d .build/doctrees . .build/html
Running Sphinx v3.1.1
making output directory... done
1.8.17
/home/rnpalmer/Debian/builds/stackbuild
Is the above intended as a proposal to remove asynctest?
The rdeps in Debian are hypercorn, python-aioresponses, and (for
autopkgtest only) python-fakeredis.
hypercorn upstream have stopped using it:
https://gitlab.com/pgjones/hypercorn/-/commit/80e2ad5db107c42d42471ea64764d2b42202349c
The ot
On 29/06/2020 20:59, Paul Gevers wrote:
Does this mean that numpy should add a Breaks relation on the old pandas
version to avoid upgrading numpy but not pandas on user systems?
Not really - the constant was replaced by its value, so the only
1.19-related change outside of tests is the reworde
Control: tag -1 upstream patch
(untested)
This is in test code not library code, so it should be fine to ignore
the warnings for now.
A nearby comment notes that a simple == won't work on all the types that
keys[0] can be, but this probably will:
--- a/pandas/tests/frame/test_alter_axes.py
Control: reopen -1
Control: reassign -1 autopkgtest/5.12.1
Control: tags -1 patch
Then we should change the documentation to state the actual policy...
(Found this after
https://lists.debian.org/debian-med/2020/04/threads.html#00074 )
--- a/doc/README.package-tests.rst
+++ b/doc/README.packag
On 07/04/2020 18:55, Paul Gevers wrote:
However, you can change the phrasing. E.g.:
For Debian, the ftp-master have ruled that tests must not execute code
they download. In particular, tests must not use external repositories
to depend on software (as opposed to data) that is not in Debian.
Howe
Existing discussion of this package's dependencies:
https://lists.debian.org/debian-med/2020/04/threads.html#00065
Summary:
- Python part: 2 tests depend on tensorflow (which is known to be hard
to package), but the rest doesn't so skipping these tests is an option.
- JavaScript part: npm2deb sa
It does (and eslint itself is one of the packages that we do have but
npm2deb can't find), but even ignoring build dependencies completely and
assuming we can use the plotly.js embedded in python3-plotly or
r-cran-plotly, the recursive dependency tree is >300 different
not-yet-packaged modules.
An upstream comment says common.py:lazy_property is the problem item,
and excluding that from the documentation does make Sphinx succeed (I
haven't tested a whole build):
--- snakemake-5.10.0.orig/docs/conf.py
+++ snakemake-5.10.0/docs/conf.py
@@ -107,6 +107,8 @@ pygments_style = 'sphinx'
# If
This might fix the remaining errors (but has not been tested):
https://docs.python.org/3/library/hmac.html#hmac.new
--- tests/unit/utils/test_utils.py~ 2020-04-09 11:02:26.967201681 +0100
+++ tests/unit/utils/test_utils.py 2020-04-09 11:02:26.991202140 +0100
@@ -85,7 +85,7 @@ class TestP
Control: reopen -1
Upstream has moved to https://github.com/DataTables (see the base
datatables.js package). As well as the Bootstrap 4 styling option,
there are two new extensions (RowGroup and SearchPanes), and probably
other changes.
Each extension is now a separate upstream repository,
Package: node-lodash-reevaluate
Version: 3.0.0-1
Severity: serious
Tags: patch
debian/tests/control has a stray . in the package name. As there is no
package with this name, this causes the test to fail as uninstallable.
Package: pegjs
Version: 0.10.0-1
Tags: patch
Severity: serious
debian/control lists a Provides: nodejs.
This is obviously wrong, and also causes the autopkgtest to fail by not
installing the real nodejs.
Package: node-unicode-13.0.0
Version: 0~20200315+gitfc57d75a-2
Severity: serious
Tags: patch
The autopkgtest includes the versioned package name (in both
debian/tests/control and debian/tests/require). As these were not
updated when this changed from 12 to 13, the autopkgtest fails as
uninsta
Package: node-rw
Version: 1.3.3-1
Severity: serious
Tags: patch
One of this package's upstream tests (encoding-async) requires
(node-)d3-queue. It build-depends on this, but does not test-depend on
it (debian/tests/control last test), so the autopkgtest fails.
This is because /usr/bin/pegjs exists in node-pegjs 0.7 but not 0.10.
(/usr/share/nodejs/bin/pegjs exists instead; I have not yet checked
whether it works.)
pegjs maintainer: is this an intentional change or a mistake? The
upstream documentation still mentions the command:
https://sources.de
Package: python3-theano
Version: 1.0.4+dfsg-2
Severity: serious
#graphlib-dot.js
make -C debian/missing-source/graphlib-dot --always-make dist
make[2]: Entering directory
'/build/theano-1.0.4+dfsg/debian/missing-source/graphlib-dot'
pegjs -e 'module.exports' src/dot-grammar.pegjs lib/dot-gramma
Control: retitle -1 schema-salad FTBFS: python-rdflib-jsonld too new
Control: tags -1 fixed-upstream patch
This explicit version check was relaxed (without other changes) in the
next upstream commit, though I haven't tested this change:
https://github.com/common-workflow-language/schema_salad/
This is probably a reference to this part of the pyopencl source:
https://sources.debian.org/src/pyopencl/2019.1.1-1/pyopencl/compyte/ndarray/pygpu_ndarray.cpp/
I have manually run the tests before (while investigating #893050), but
I don't know how beyond 'make tests'.
Control: retitle -1 pandas FTBFS: deprecations/improvements fail tests
The message on the old title is just a warning, but there are 6 other
tests that fail.
I think these are all bugs in the tests not the actual package, i.e.
using our current pandas is fine.
Deprecation warnings in fail-o
Package: qa.debian.org
User: qa.debian@packages.debian.org
Usertags: udd
Some packages have a dash in the watch column of
qa.debian.org/developer.php and this error message on tracker.debian.org:
uscan had problems while searching for a new upstream version:
In watchfile debian/watch, rea
Control: tags -1 pending
Control: block -1 by 955399
I just pushed what I think is a fix to salsa, but pandas is currently
BD-Uninstallable due to xvfb (#955399), so it has not been tested.
Package: python3-theano
Version: 1.0.4-1
Severity: serious
Justification: at least one looks like a silently wrong answer
The tests passed (at least on amd64) when 1.0.4-1 was first uploaded,
but 9 tests failed when it was rebuilt as 1.0.4-1+b1 (for Python 3.8,
but I suspect the actual cause wa
Control: severity -1 normal
Control: tags -1 upstream patch pending
Control: forwarded -1 https://github.com/Theano/theano/pull/6749
On closer inspection, this isn't a "silently wrong answer" bug after
all, so lowering the severity. Some parts of it appear to be caused by
numpy 1.17 and some p
Control: severity -1 serious
Control: tags -1 fixed-upstream patch
test_full_output*:
https://github.com/statsmodels/statsmodels/issues/6771
test_plot:
https://github.com/statsmodels/statsmodels/commit/fa8739e9d2822fe985bc96cd31bb3eb568fd9dc7
Package: shim-helpers-amd64-signed
Version: 1+15+1533136590.3beb971+7+deb10u1
(I don't know if this is actually a bug)
This package does not have any maintainer scripts. Hence, an update
places new versions of fbx64+mmx64 in /usr/lib/shim, but leaves the old
ones in /boot/efi.
shim-signed d
Package: python3-pandas
Version: 0.25.3+dfsg2-4
Severity: serious
One test fails on i386 with a 1-in-last-place difference, probably due
to different rounding (x87 extra precision?).
https://buildd.debian.org/status/fetch.php?pkg=pandas&arch=i386&ver=0.25.3%2Bdfsg2-4&stamp=1597048961&raw=0
Package: python3-statsmodels
Version: 0.11.1-4
Severity: serious
arm64 fail in TestZeroInflatedModel_probit.test_fit_regularized:
https://buildd.debian.org/status/fetch.php?pkg=statsmodels&arch=arm64&ver=0.11.1-4&stamp=1597051632&raw=0
https://ci.debian.net/packages/s/statsmodels/testing/arm64/
Package: qa.debian.org
User: qa.debian@packages.debian.org
Usertags: udd
Bug titles containing non-ASCII characters work in the BTS:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966851
but not in the UDD bug listings, or the autoremovals notices generated
from them:
https://udd.debian
This doesn't crash when just that test file is run in statsmodels
0.11.1-3 qemu-armel, but this isn't 100% proof that -4 (rather than a
dependency) caused it.
-4 (built locally in qemu) doesn't crash that way either, which suggests
this bug doesn't show up in qemu, and (given the lack of relev
The TestZeroInflatedModel_probit issue appears to be a failure to
converge: as it does trigger warnings of that, and it's already skipped
on i386, I intend to ignore it.
qemu-arm64:
>>> a
object at 0x4000d31130>
>>> a.res1.params
Traceback (most recent call last):
File "", line 1, in
Attri
Using --forked revealed that the above is one of 21 test crashes on
armel, and that there are also 2 wrong answers.
The ones I have tried (the wrong answers and most of the crashes) are
not reproducible on qemu-armel.
Control: tags -1 fixed-upstream patch
Control: severity -1 important
(Raising severity because pandas 2.x is currently blocking Python 3.12)
This looks like the upstream fix (I haven't tried it in Debian):
https://github.com/mwaskom/seaborn/pull/3355
Upgrading to upstream 0.13 would probably als
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
c
That might not be enough: some of pandas' pytables-using tests are still
failing in Python 3.12 (see salsa-ci).
However, I don't know whether upgrading pytables to a newer upstream
would break anything else.
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 pyt
Control: severity -1 important
(We would like to transition to pandas 2.1 fairly soon.)
This bug can probably be fixed by replacing all 3 instances of
pandas.util.testing with pandas.testing.
There are also some (unrelated) Python 3.12 issues:
self.assertRaisesRegexp -> self.assertRaisesRegex
Control: severity -1 important
(We would like to transition to pandas 2.1 fairly soon.)
This *might* be fixed by https://github.com/dask/dask/pull/10439 and/or
https://github.com/dask/dask/pull/10531
It might be best to update to a new upstream version, which would
include those and also what
Control: severity -1 important
(We would like to transition to pandas 2.1 fairly soon.)
Ignoring these warnings would probably work for now.
This is not obviously known upstream, but updating to a newer upstream
version might still be worth trying.
Control: severity -1 important
(We would like to transition to pandas 2.1 fairly soon.)
Replacing all instances of pandas.util.testing with pandas.testing
should fix the currently visible bug, but I haven't tried it so I don't
know whether there are also other bugs.
Control: severity -1 important
(We would like to transition to pandas 2.1 fairly soon.)
These packages are attempting to use .iteritems() on pandas objects,
which no longer exists. This can probably be fixed by using .items()
instead.
Control: unblock 1043240 by 1044050
Control: severity 1044050 serious
Control: merge 1044050 1050623
Control: retitle -1 intake: newlines in error messages
Control: tags -1 patch
On closer inspection, that's not pandas 2.x related, it's the previously
seen failure to handle error messages contai
I'd like to move forward with the pandas 1.5 -> 2.1 transition
reasonably soon.
Given that pandas 2.x is *not* required for Python 3.12 (but is required
for Cython 3.0), should we wait for the Python 3.12 transition to be
done first?
These are broken by pandas 2.x and have a possible (but un
Control: block -1 by 1043240
Control: tags -1 fixed-upstream fixed-in-experimental
pandas 2.1.4 in experimental uses Cython 3, without known issues. We
are currently discussing (in #1043240) whether to move that version to
unstable, given that it would cause other breakage.
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 h
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 the
On 10/12/2023 20:16, Julian Gilbey wrote:
> [...]I'd be in favour of doing the pandas
> transition now, which will allow Cython 3.0 to move into unstable.
Cython 3 is already in unstable; pandas is currently using cython-legacy.
And yes, my list of packages broken by pandas 2.x is those identifi
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: 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: 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:
Control: reopen -1
Please also remove theano from experimental.
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
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 buil
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
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-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
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
What, if anything, blocks the above fix from being applied now?
tqdm, influxdb-python and seaborn are the highest-popcon packages broken
by pandas 2.x.
On 22/01/2024 11:51, Julian Gilbey wrote:
Please could we wait until the "Python 3.12 is a supported version"
transition is completed?
How are you defining that? python3-defaults 3.11.6+ in testing? (I was
previously told 3.12-supporting pandas and numpy in testing, which has
happened. I d
That's not the only problem: some of the tests mix timestamps in
slightly different formats (with and without fractional seconds), which
is no longer allowed by default:
https://pandas.pydata.org/pandas-docs/version/2.1.4/whatsnew/v2.0.0.html#datetimes-are-now-parsed-with-a-consistent-format
Th
The above by itself wasn't enough, but what I have now pushed to Salsa
is. Please upload it.
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
fa
801 - 900 of 1024 matches
Mail list logo
