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,
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
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.
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.
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)
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
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
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
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.
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.
(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
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
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.
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
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
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
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
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
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
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
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
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: 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: 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
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.
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
Probably fixed - see my merge request on Salsa.
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
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
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
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.)
Control: tags -1 pending
Looks like rounding error in a test; ignored in Salsa.
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
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
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
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: 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.
Package: python3-openpyxl
Version: 3.0.9-2
Severity: wishlist
Control: affects -1 python3-pandas
Upstream pandas 2.1 will only use openpyxl >= 3.0.10. If I override
this to accept Debian's 3.0.9, I get 2 test failures that plausibly
might be caused by it (but I haven't actually tried it with a
Package: python3-tabulate
Version: 0.8.9-1
Severity: wishlist
Upstream pandas 2.1 will only use tabulate >= 0.8.10. Nothing obviously
breaks if I override this to accept Debian's 0.8.9, but it might be
better to actually update tabulate.
(At least to the latest 0.8.x - I don't know whether g
Salsa has 0.8.10, but it's been there for some time and I don't know why
it hasn't been uploaded.
Package: python3-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
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.
Possibly useful here: gdb disassemble works inside pocl kernels, see
#920497 for an example.
Is the file you're trying to open .xlsx or .xls? Do you have
python3-openpyxl installed? If .xlsx and no, try installing it.
(python3-)xlrd 2.0+ can only open .xls files, not .xlsx. Hence, pandas
1.5+ read_excel() always uses (python3-)openpyxl for .xlsx files.
python3-pandas already Recomm
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.
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.
Control: reassign -1 python3-xlrd
Control: affects -1 python3-pandas
Control: retitle -1 pandas can't open xls (not xlsx) files, xlrd too old
Then yes, you do need xlrd. As Debian is currently in freeze, I suggest
installing it from PyPI (warning, this doesn't automatically install
security up
I don't consider the lack of .xls in pandas worth a freeze exception,
but consider it reasonable for others to disagree with that.
As noted in the bug, there are some (possibly not-technically-valid)
.xlsx files that xlrd 1 can open but openpyxl can't - _pandas_ won't be
able to open those eit
I agree that switching to Aesara is probably the only reasonable option
other than removal. (I'd given up on trying to fix 1.0, and was
intending to let removal happen.)
However, it's a much bigger change than is normally allowed in bookworm
at this point. (1.1 includes multiple breaking cha
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 that
I pushed this fix to Salsa as the 'fix1049326' branch - it isn't enough
to fix pandas by itself, but is plausibly an improvement.
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.)
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
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.
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
Control: tags -1 pending
Fixed in Salsa, but please do NOT upload that version as-is (it FTBFS
for an unrelated reason).
Package: src:emperor
Version: 1.0.3+ds-7
Control: block 1043240 by -1
emperor fails to build with pandas 2.0, currently in experimental.
Build log:
https://launchpadlibrarian.net/682917876/buildlog_ubuntu-mantic-amd64.emperor_1.0.3+ds-7_BUILDING.txt.gz
A common source of failures is that pandas
Control: severity -1 serious
That wasn't a fix - log with pocl 4:
https://ci.debian.net/data/autopkgtest/testing/i386/libg/libgpuarray/37023715/log.gz
Package: python3-nbclient
Version: 0.8.0-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
By default, nbclient includes timestamps in its output, which makes
packages built with it (e.g. python-pandas-doc) unreproducible.
It provides a rec
Package: python3-sphinx
Version: 5.3.0-7
Severity: wishlist
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fileordering
When the same function has two entries in the table of contents, that
function's documentation page may be generated with the table of
contents open to either of
Package: python3-pandas
Version: 1.5.3+dfsg-6
Tags: fixed-upstream fixed-in-experimental
User: debian-pyt...@lists.debian.org
Usertags: python3.12
Control: block -1 by 1043240
Control: forwarded -1 https://github.com/pandas-dev/pandas/issues/53665
(actually found independently)
pandas 1.5 FTBFS w
Source: openpyxl
Version: 3.0.9-2
Severity: serious
licensecheck -r --copyright . on openpyxl finds these:
./openpyxl/formatting/tests/data/conditional-formatting.xlsx: UNKNOWN
[Copyright: 2007 Apple Inc.]
./openpyxl/reader/tests/data/complex-styles.xlsx: UNKNOWN
[Copyright: 2007 Apple Inc.]
Control: retitle -1 transition: pandas 1.5 -> 2.1
pandas 2.1 is now in experimental. In addition to the above, it breaks
these packages:
astropy dask patsy pymatgen python-cooler python-geopandas q2-demux
q2-taxa q2-types seaborn tqdm
and maybe python-hypothesis.
(python-pauvre and sunpy are
Package: src:pymatgen
Version: 2023.06.23+dfsg1-2
Control: block 1043240 by -1
pymatgen fails its tests with pandas 2.1, currently in experimental.
Logs:
https://ci.debian.net/data/autopkgtest/unstable/amd64/p/pymatgen/38997822/log.gz
https://launchpad.net/~rebecca-palmer/+archive/ubuntu/pandas
Package: src:python-cooler
Version: 0.9.1-1
Control: block 1043240 by -1
python-cooler fails its autopkgtest with pandas 2.1, currently in
experimental.
Log:
https://ci.debian.net/data/autopkgtest/unstable/amd64/p/python-cooler/38997833/log.gz
A common source of failures is new pandas FutureW
Package: src:python-geopandas
Version: 0.14.0-1
Control: block 1043240 by -1
python-geopandas fails its autopkgtest with pandas 2.1, currently in
experimental.
Log:
https://ci.debian.net/data/autopkgtest/unstable/amd64/p/python-geopandas/38997837/log.gz
A common source of failures is new pand
Package: src:q2-demux
Version: 2023.7.0+dfsg-1
Control: block 1043240 by -1
q2-demux fails its autopkgtest with pandas 2.1, currently in experimental.
Log:
https://ci.debian.net/data/autopkgtest/unstable/amd64/q/q2-demux/38997862/log.gz
A common source of failures is new pandas FutureWarnings i
Package: src:q2-taxa
Version: 2023.7.0+dfsg-1
Control: block 1043240 by -1
q2-taxa fails its autopkgtest with pandas 2.1, currently in experimental.
Log:
https://ci.debian.net/data/autopkgtest/unstable/amd64/q/q2-taxa/38997868/log.gz
A common source of failures is new pandas FutureWarnings in t
Package: src:q2-types
Version: 2023.7.0-1
Control: block 1043240 by -1
q2-types fails its autopkgtest with pandas 2.1, currently in experimental.
Log:
https://ci.debian.net/data/autopkgtest/unstable/amd64/q/q2-types/38997869/log.gz
A common source of failures is new pandas FutureWarnings in tes
Package: src:seaborn
Version: 0.12.2-1
Control: block 1043240 by -1
seaborn fails its tests with pandas 2.1, currently in experimental.
Logs:
https://ci.debian.net/data/autopkgtest/unstable/amd64/s/seaborn/38997875/log.gz
https://launchpad.net/~rebecca-palmer/+archive/ubuntu/pandas2p1/+build/267
Package: src:tqdm
Version: 4.64.1-1
Control: block 1043240 by -1
tqdm fails to build with pandas 2.1, currently in experimental.
Log:
https://launchpad.net/~rebecca-palmer/+archive/ubuntu/pandas2p1/+build/26770822/+files/buildlog_ubuntu-mantic-amd64.tqdm_4.64.1-1_BUILDING.txt.gz
A common source
Package: src:dask
Version: 2023.8.0+dfsg-2
Control: block 1043240 by -1
dask fails its autopkgtest with pandas 2.1, currently in experimental.
Log:
https://ci.debian.net/data/autopkgtest/unstable/amd64/d/dask/38997774/log.gz
A common source of failures is new pandas FutureWarnings in tests that
Package: src:patsy
Version: 0.5.3-1
Control: block 1043240 by -1
patsy fails to build with pandas 2.1, currently in experimental.
Log:
https://launchpad.net/~rebecca-palmer/+archive/ubuntu/pandas2p1/+build/26770725/+files/buildlog_ubuntu-mantic-amd64.patsy_0.5.3-1_BUILDING.txt.gz
A common sourc
astropy isn't actually a regression (i.e. it's probably _a_ bug, but
unrelated to pandas 2.x), and python-hypothesis appears to be fixed (by
upstream, in 6.83.1). I have filed individual bugs for the others.
Package: python3-xlsxwriter
Version: 3.0.2-2
Severity: wishlist
Tags: fixed-upstream
Upstream pandas 2.1 will only use xlsxwriter >= 3.0.3. Nothing
obviously breaks if I override this to accept Debian's 3.0.2, but it
might be better to actually update xlsxwriter.
Control: reopen -1 1026539
theano has been mostly abandoned upstream since 2018. (The Aesara fork
is not abandoned, but includes interface changes including the import
name, so would break reverse dependencies not specifically altered for it.)
It is currently broken (FTBFS due to multiple te
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
Package: ftp.debian.org
beignet FTBFS with LLVM > 9 (#974792), and hence cannot be built in
current unstable. (The existing package probably still works, because
beignet statically links LLVM to avoid #852746, but unbuildable packages
are unreleasable by policy.)
beignet is abandoned upstre
sorry, discussion on pkg-opencl-devel / debian-devel around 19 June, not
actually in #974792
Control: tags -1 fixed-upstream patch
This is probably caused by the new fsspec version, and is also seen in
autopkgtest:
https://ci.debian.net/data/autopkgtest/testing/amd64/p/pandas/36146393/log.gz
Upstream fix:
https://github.com/pandas-dev/pandas/commit/ce9e3d658d6efa3600a4563ca7a00e7a15b8
Package: python3-numexpr
Version: 2.8.5-1
Severity: serious
Control: forwarded -1 https://github.com/pandas-dev/pandas/issues/54449
(actually they found it first)
I only have actual logs for 2.0.x, but I suspect 1.5.x is also affected.
As a short term fix, it may be possible to disable pandas' n
Control: forwarded -1 https://github.com/pandas-dev/pandas/issues/54546
Control: affects -1 python3-pandas
There's actually *two* bugs here: an exception in eval/query,
https://github.com/pandas-dev/pandas/issues/54449, and a changed result
with integer overflow, https://github.com/pandas-dev/p
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
beignet FTBFS with LLVM > 9 (#974792). beignet uses libllvm/libclang
heavily enough that it usually has this kind of bug on a new LLVM
release, but this time my attempts to fix it failed (see the Salsa CI logs).
It is abandoned upstream and mostly replaced by intel-opencl-icd. (This
is not a
Additional information:
As a rough estimate of how much speed this would cost on older hardware,
I previously measured beignet as 8-16x faster than pocl (but this will
obviously depend on hardware and application). However, beignet (on
hardware that can't use intel-opencl-icd) is limited to s
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 x
Control: reopen -1
Control: tags -1 pending
Control: tags 1066801 pending
Control: tags 1064384 pending
Sorry, that wasn't actually a fix, but what's now in Salsa should be.
Control: tags -1 pending
This has happened before (see #968210), with the same 'fix'.
Test skip in Salsa, but please do not upload it right now as it has not
yet been tested.
Package: ftp.debian.org
User: ftp.debian@packages.debian.org
Usertags: remove
libgpuarray has been de facto abandoned upstream since 2018, and is
unused in Debian since theano was removed (#1042574).
It currently has what may or may not be a wrong-answer bug (#1031414),
and two broken-by-
These tests are now skipped in Debian (for unrelated reasons), so this
bug is no longer caught by the autopkgtest, but probably does still exist.
Control: severity 1053943 1053939 1053942 1044053 1044056 serious
Control: severity 1044074 1053946 1044078 1044079 1044077 serious
Control: severity 1044071 1044067 1044068 1044055 1044060 serious
Control: severity 1044072 1044073 1044064 1053945 1044054 serious
Control: severity 1044076 1053940
Control: tags -1 fixed-upstream patch
The test failure is that np.array @ pd.DataFrame (matrix product) tries
to keep both the DataFrame's indices, which fails because the new matrix
is a different shape.
This appears to be fixed in 0.24.1 from PyPI, but as previously noted,
this is a new ma
Package: freefem3d
Severity: serious
This package is dead upstream, and it has been suggested [0] that
because of this, it should not be fixed for buster.
I don't know enough about it to have an opinion on this: I am opening
this bug as a "don't waste your time fixing it" notice.
If this re
Package: clsparse
Severity: serious
X-Debbugs-Cc: debian-scie...@lists.debian.org, ghisv...@gmail.com
(plus an identical one for freefem3d)
This package is dead upstream, and it has been suggested [0] that
because of this, it should not be fixed for buster.
I don't know enough about it to have
Control: tags -1 fixed-upstream patch
These look like the upstream fixes, though I haven't actually tried them
yet.
for index:
https://github.com/arrayfire/arrayfire/commit/58ac59497b50257631713e689a6b0ddffb73361a
for assign:
https://github.com/arrayfire/arrayfire/commit/1b18226dfec811e4b7b
On i386 with the above patches (plus the gcc8 build fix from the other
bug), all tests pass in the build but Test_gfor_cpu fails in the
autopkgtest; I don't yet know why.
Package: clblas
Version: 2.12-1
Control: tags -1 patch
(Split from #881054: cloning a merged bug is not allowed, and both
original reports better match the other part.)
After a compile failure (e.g. due to #881054), clblas crashes trying to
dereference a NULL pointer.
Fix:
diff --git a/src
with what looks
like https://github.com/clMathLibraries/clBLAS/issues/338.
Description: Don't use double literals in single precision functions
Allows it to work on single-precision-only hardware/ICDs e.g. beignet
Author: Rebecca N. Palmer
Bug-Debian: https://bugs.debian.org/877316
Forwar
uthor: Rebecca N. Palmer
Bug-Debian: https://bugs.debian.org/
Forwarded: no
--- clblas-2.12.orig/src/library/blas/gens/clTemplates/trmv.cl
+++ clblas-2.12/src/library/blas/gens/clTemplates/trmv.cl
@@ -75,6 +75,8 @@ __kernel void %PREFIXtrmv_CU_kernel( __g
__local %TYPE sXData[ TARGET_WIDTH ]; //
401 - 500 of 1024 matches
Mail list logo
