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.
Package: python3-pandas
Version: 0.25.3+dfsg-9
Severity: serious
Tags: fixed-upstream patch
numpy 1.18 includes two behaviour changes that affect pandas, causing a
CI fail / presumed FTBFS.
Both are fixed in pandas 1.0 (in experimental, but moving that to
unstable causes other issues, see #95
Control: tags -1 patch
The failed tests are expecting an 0/0 warning from numpy, which it
produces on amd64 but not armel:
amd64$ python3
Python 3.8.2 (default, Apr 1 2020, 15:52:55)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy a
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/
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
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
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
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.
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: 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 python3-sphinx-astropy
Control: tags -1 patch
(untested)
(If reading this in the bug, see
https://lists.debian.org/debian-mentors/2020/01/msg00295.html.)
An intersphinx_mapping can specify multiple alternatives for where to
find the inventory referred to, and these can be
Package: python3-seaborn
Version: 0.9.0-2
Severity: serious
Found during statsmodels transition testing, but also occurs without
statsmodels. I have not investigated further.
__ TestFacetGrid.test_set_ticklabels
___
self =
def test_set_ticklabe
The linked upstream report says this went away in numpy 1.18.4, and the
tests in question now pass on debci.
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
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
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
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
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
This fix causes Sphinx to fail if documenting an object whose
__getattr__ fails, e.g. flask.request. This causes at least snakemake
to FTBFS.
Details and fix:
https://github.com/sphinx-doc/sphinx/pull/7520
A workaround in failing packages is to add
autodoc_default_options = {'exclude-members'
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: tags -1 fixed-upstream
https://sourceforge.net/p/flightgear/fgrun/ci/312a8de41336cfe6d85336e8909b517e0c590c0c/
(We might need the next commit as well; given how little has changed,
probably easiest to take the whole upstream release)
Source: beignet
Severity: serious
Control: tags -1 upstream patch
beignet started using drm_intel_get_pooled_eu and
drm_intel_get_min_eu_in_pool if available early in their development,
before their interface was finalized, and hence does not build with the
released version (libdrm-intel 2.4.7
The tests in question are checking that numexpr and numpy give the same
answers (by default, pandas uses numexpr if available for large arrays
but numpy for small ones), and require integers to match exactly. The
failing values are all 15**15, which is 437893890380859375 in exact
arithmetic bu
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
Thanks - I plan to look at this tomorrow.
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 https://salsa.de
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 th
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 sta
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
src:python
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 becau
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 o
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.
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
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 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
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
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 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: 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
This does seem to have worked: the openblas build log no longer contains
FATAL ERROR.
Hence, please give back statsmodels on mips64el. (DMs aren't allowed to
use the self-service link.)
Control: 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 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
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
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.
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.
lmo's 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 w
This has been merged but not uploaded - is there a reason it shouldn't
be, or have you just not had time?
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.)
th
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.
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-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:
https://ci.debian.n
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: 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:
https://salsa.debian.org/med-team/snakemake/-/commit/607bd710a51b77502c641443cf6
Control: tags -1 patch
See the Salsa merge request.
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.
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 fix worked but the new upstream version added another similar
issue, so s390x failed again.
I have pushed a fix for this, and enabled allow-stderr to fix armel
(error output from an already-xfailed test). I don't know what's
causing the hang on arm64, so please do _not_ upload this just
I 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.
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
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
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
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*
ver
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 m
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 t
Fix committed to Alioth.
This fix has been accepted upstream; they found that it exposed another
bug that compare and type-convert don't properly handle constants
(http://lists.freedesktop.org/archives/beignet/2014-November/004387.html),
so I included the fix for that as well.
My own testing
Package: flightgear-data-base
Version: 3.0.0-1
Severity: grave
Justification: renders package unusable
Control: tags -1 patch
A fresh install (no .fgfs) of amd64 flightgear in current jessie or
current sid fails to start:
Program received signal SIGABRT, Aborted.
0x71d6f077 in __GI_rai
Control: reassign -1 src:simgear
Control: found -1 3.0.0-5
Control: merge -1 765932
These are both the same kfreebsd FTBFS; this (#765818) patch looks
better, but I haven't tried either.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Troub
ebian/changelog
@@ -1,3 +1,10 @@
+flightgear-data (3.0.0-2) UNRELEASED; urgency=medium
+
+ * Fix type mismatch crash. Closes: #766251.
+ * Downgrade -ai, -aircrafts to Recommends.
+
+ -- Rebecca N. Palmer Wed, 22 Oct 2014 18:27:01
+0100
+
flightgear-data (3.0.0-1) unstable; urgency=low
dpkg-source --commit produced a patch with all Unix line endings, which
failed; running that through unix2dos gave a patch with all DOS line
endings, which also failed, with
(Stripping trailing CRs from patch; use --binary to disable.)
patching file Effects/model-combined-transparent.eff
Hunk #
4-04-19
18:54:55.0 +0100
+++ beignet-0.8/debian/patches/versioned-llvm-tools 2014-10-28
12:17:01.0 +
@@ -1,9 +1,20 @@
Description: Use versioned LLVM tools
-Author: Simon Richter
-Last-Update: 2014-04-19
+Description:
+Author: Simon Richter , Rebecca N. Palmer
Source: libjogl2-java
Version: 2.2.4-1
Severity: serious
Justification: Policy 2.1
Control: found -1 2.1.5-2
src/test/com/jogamp/opengl/test/junit/jogl/demos/es2/shader/landscape.fp
has a NonCommercial license, which is not allowed in Debian (even if the
file isn't actually used: https://releas
Package: beignet
Version: 0.8-1.1
Severity: serious
Justification: Policy 2.1
Control: tags -1 patch upstream
X-Debbugs-CC: pkg-opencl-de...@lists.alioth.debian.org
The beignet test suite contains three images derived from Lenna (
kernels/lenna128x128.bmp kernels/compiler_box_blur_float_ref.bmp
I'm just wondering where
the build failure in late August with exactly those dependencies came
from and why the change fixed them?
during compilation clang
was called but could not be found:
[...]
Only the clang metapackage but not the clang-some.version package
provides /usr/bin/clang.
Agre
Control: forwarded -1
http://lists.freedesktop.org/archives/beignet/2014-October/004343.html
I have reported this upstream; they have agreed it's a problem and are
in the process of removing the first group and investigating the second.
To deal with this problem in the meantime, we will need to
*mandelbrot* were included in this report by mistake, and are actually
OK to keep.
Now it FTBFS (it was working before the dfsg changes), tail of buildlog:
I get the same error with git-buildpackage, but success with
dpkg-buildpackage (as root in cowbuilder --login chroot; not cowbuilder
--bu
You have my blessing to change the maintainer field if you like, as I
won't be able to do as much as is needed in the next days.
It would probably make sense for the pkg-opencl-devel list to own this
package; I'm willing to be named as uploader, but will need a sponsor to
actually upload anyth
.4, update versioned-llvm-tools.patch.
+(Closes: #764930)
+ * State in the description what hardware this supports.
+
+ -- Rebecca N. Palmer Sat, 01 Nov 2014
14:01:26 +
+
beignet (0.8-1.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru beignet-0.8/debian/control beigne
if f[0] in ("pow(a[i],c[i])","powr(a[i],c[i])"):
d0=f[1](c,c)
elif f[0] in ("pown(a[i],d[i])",):
d0=f[1](c,ci)
else:
d0=f[1](c)
print(dCL.get(),"\n",d0)
Description:
TODO: Put a short sum
I think the trigger is nvidia-opencl-icd adding a new dependency on
libcuda1 (changelog: Add libcuda1 dependency to libraries that seem to
be capable of doing dlopen("libcuda.so") or dlopen("libcuda.so.1").),
which pulls in the rest of nvidia-* as libcuda1 Recommends:
nvidia-kernel-dkms which R
201 - 300 of 388 matches
Mail list logo
