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.
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.
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.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
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.
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
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 1.5
declares
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 1.5
declares
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
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
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.)
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.)
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:
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:
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
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
It also doesn't fail on the buildds. (The failed binNMU of statsmodels
for Python 3.11 is instead the expected result of trying to build
statsmodels on a Python version without pandas - pandas failed due to
#1023965.)
Is there anything special about the mass-rebuild environment that might
Control: block 1021984 by -1
Control: tags -1 fixed-upstream fixed-in-experimental
There's more than just those 2[0].
Some are tests that expect an error and check the message (not just the
type), and fail because the message has been reworded - these should be
trivial to fix.
The 2 in
Control: block 1021984 by -1
Control: tags -1 fixed-upstream fixed-in-experimental
There's more than just those 2[0].
Some are tests that expect an error and check the message (not just the
type), and fail because the message has been reworded - these should be
trivial to fix.
The 2 in
Control: 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
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 -
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
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
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
Rebecca N. Palmer pushed to branch master at Debian Med / snakemake
Commits:
8868dd08 by Rebecca N. Palmer at 2022-03-31T21:16:57+01:00
retry CI (after pushing other branches)
- - - - -
1 changed file:
- debian/changelog
Changes:
=
debian/changelog
Rebecca N. Palmer pushed new tag upstream/7.3.3 at Debian Med / snakemake
--
View it on GitLab:
https://salsa.debian.org/med-team/snakemake/-/tree/upstream/7.3.3
You're receiving this email because of your account on salsa.debian.org.
___
debian
Rebecca N. Palmer pushed to branch pristine-tar at Debian Med / snakemake
Commits:
c0852f2c by Rebecca N. Palmer at 2022-03-29T21:00:04+01:00
pristine-tar data for snakemake_7.3.3.orig.tar.gz
- - - - -
2 changed files:
- + snakemake_7.3.3.orig.tar.gz.delta
- + snakemake_7.3.3
Rebecca N. Palmer pushed to branch upstream at Debian Med / snakemake
Commits:
b1bb3d3f by Rebecca N. Palmer at 2022-03-29T20:59:38+01:00
New upstream version 7.3.3
- - - - -
30 changed files:
- .github/workflows/main.yml
- .gitpod.yml
- .readthedocs.yml
- CHANGELOG.md
- LICENSE.md
Rebecca N. Palmer pushed to branch master at Debian Med / snakemake
Commits:
6be4ab3c by Rebecca N. Palmer at 2022-03-30T07:41:06+01:00
skip a test that now needs python3-retry, add missing test-depends
- - - - -
8f6abdbf by Rebecca N. Palmer at 2022-03-30T07:42:41+01:00
Update Lintian
Rebecca N. Palmer pushed to branch master at Debian Med / snakemake
Commits:
978041ef by Rebecca N. Palmer at 2022-03-29T23:06:40+01:00
fix test skips
- - - - -
3 changed files:
- debian/changelog
- debian/rules
- debian/tests/run-unit-test
Changes
Rebecca N. Palmer pushed to branch master at Debian Med / snakemake
Commits:
b1bb3d3f by Rebecca N. Palmer at 2022-03-29T20:59:38+01:00
New upstream version 7.3.3
- - - - -
b2e06151 by Rebecca N. Palmer at 2022-03-29T21:00:04+01:00
Update upstream source from tag upstream/7.3.3
Update
Rebecca N. Palmer pushed new tag debian/6.15.5-1 at Debian Med / snakemake
--
View it on GitLab:
https://salsa.debian.org/med-team/snakemake/-/tree/debian/6.15.5-1
You're receiving this email because of your account on salsa.debian.org.
___
debian
Rebecca N. Palmer pushed new tag upstream/6.15.5 at Debian Med / snakemake
--
View it on GitLab:
https://salsa.debian.org/med-team/snakemake/-/tree/upstream/6.15.5
You're receiving this email because of your account on salsa.debian.org.
___
debian
Rebecca N. Palmer pushed to branch pristine-tar at Debian Med / snakemake
Commits:
55fcf68f by Rebecca N. Palmer at 2022-02-20T13:30:09+00:00
pristine-tar data for snakemake_6.15.5.orig.tar.gz
- - - - -
2 changed files:
- + snakemake_6.15.5.orig.tar.gz.delta
- + snakemake_6.15.5
Rebecca N. Palmer pushed to branch master at Debian Med / snakemake
Commits:
da1a9e8d by Rebecca N. Palmer at 2022-02-20T14:41:54+00:00
Tests: skip peppy tests (not in Debian).
- - - - -
1d9c1c81 by Rebecca N. Palmer at 2022-02-20T14:53:22+00:00
Tests: use Python 3 subprocesses
Rebecca N. Palmer pushed to branch master at Debian Med / snakemake
Commits:
3e2242a4 by Rebecca N. Palmer at 2022-02-20T13:58:27+00:00
Remove drmaa Recommends, as that package is broken (see #951704).
- - - - -
3 changed files:
- debian/README.source
- debian/changelog
- debian/control
I didn't mean that these other non-packaged options were direct
alternatives to drmaa, only that snakemake already doesn't have all its
features available in Debian without installing external packages, and
that I don't consider losing one more to be a serious bug.
If anyone _wants_ to work
The documentation says:
https://github.com/snakemake/snakemake/blob/main/docs/tutorial/additional_features.rst#cluster-execution
https://github.com/snakemake/snakemake/blob/main/docs/executing/cluster.rst
I don't know how up to date this is, but the code to use drmaa is still
there.
snakemake
pandas has now migrated (on both Debian and Ubuntu).
I have uploaded versions of statsmodels and snakemake that should
(almost always) avoid these test failures, and reported the partd
failure as #1005045.
Rebecca N. Palmer pushed to branch pristine-tar at Debian Med / snakemake
Commits:
f4fe5afd by Rebecca N. Palmer at 2022-02-01T21:13:29+00:00
pristine-tar data for snakemake_6.15.1.orig.tar.gz
- - - - -
3bb6c55c by Rebecca N. Palmer at 2022-02-05T21:21:16+00:00
Merge branch pristine-tar
Rebecca N. Palmer pushed to branch upstream at Debian Med / snakemake
Commits:
cb7ce873 by Rebecca N. Palmer at 2022-02-01T21:13:08+00:00
New upstream version 6.15.1
- - - - -
bebee42a by Rebecca N. Palmer at 2022-02-05T21:21:48+00:00
Merge branch upstream of salsa.debian.org:med-team
Rebecca N. Palmer pushed new tag debian/6.15.1-2 at Debian Med / snakemake
--
View it on GitLab:
https://salsa.debian.org/med-team/snakemake/-/tree/debian/6.15.1-2
You're receiving this email because of your account on salsa.debian.org.
___
debian
Rebecca N. Palmer pushed to branch master at Debian Med / snakemake
Commits:
5b3400fa by Rebecca N. Palmer at 2022-02-04T22:36:43+00:00
Timeout and retry an intermittently hanging autopkgtest.
- - - - -
3 changed files:
- debian/changelog
- debian/rules
- debian/tests/run-unit-test
In Debian (only change from -1 should be disabling some tests, i.e. real
pandas-related failures are unlikely):
mdtraj/amd64: upstream tests pass but a warning is printed to stderr,
which autopkgtest counts as a fail
partd/ppc64el: save/load of a plain string fails
snakemake/i386: hang in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Please upload snakemake 6.15.1-1 to unstable
(Salsa HEAD = commit ID 8bf4db496feed2fa84f23018acba0033e321ef69).
This splits the binary package into snakemake and snakemake-doc,
which I can't do myself because DMs can't upload NEW packages.
Rebecca N. Palmer pushed to branch master at Debian Med / snakemake
Commits:
8bf4db49 by Rebecca N. Palmer at 2022-02-02T07:36:30+00:00
Try again to fix sphinx locale (see #998059)
- - - - -
2 changed files:
- debian/changelog
- debian/rules
Changes
Rebecca N. Palmer pushed to branch master at Debian Med / snakemake
Commits:
f113de42 by Rebecca N. Palmer at 2022-02-01T22:24:58+00:00
salsa-ci: properly enable diffoscope
- - - - -
2 changed files:
- debian/changelog
- debian/salsa-ci.yml
Changes
Rebecca N. Palmer pushed to branch master at Debian Med / snakemake
Commits:
2d75b16c by Rebecca N. Palmer at 2022-02-01T21:53:58+00:00
Tests: skip another new conda-using test.
- - - - -
3 changed files:
- debian/changelog
- debian/rules
- debian/tests/run-unit-test
Changes
Rebecca N. Palmer pushed to branch master at Debian Med / snakemake
Commits:
5467e2a2 by Rebecca N. Palmer at 2022-02-01T21:12:19+00:00
salsa-ci: disable atomic reprotest (always meant to be a one-off
given how resource-heavy it might be) but keep diffoscope
- - - - -
cb7ce873 by Rebecca N
Rebecca N. Palmer pushed to branch master at Debian Med / snakemake
Commits:
50113c1d by Rebecca N. Palmer at 2022-02-01T20:25:46+00:00
Tests: skip an FTP-using test.
- - - - -
4e527e8b by Rebecca N. Palmer at 2022-02-01T20:27:39+00:00
salsa-ci: run additional reproducibility tests
Rebecca N. Palmer pushed new tag upstream/6.14.0 at Debian Med / snakemake
--
View it on GitLab:
https://salsa.debian.org/med-team/snakemake/-/tree/upstream/6.14.0
You're receiving this email because of your account on salsa.debian.org.
___
debian
Rebecca N. Palmer pushed to branch upstream at Debian Med / snakemake
Commits:
1ee51741 by Rebecca N. Palmer at 2022-01-26T21:13:21+00:00
New upstream version 6.14.0
- - - - -
30 changed files:
- CHANGELOG.md
- docs/getting_started/installation.rst
- docs/project_info/more_resources.rst
Rebecca N. Palmer pushed to branch pristine-tar at Debian Med / snakemake
Commits:
160bfcfa by Rebecca N. Palmer at 2022-01-26T21:13:41+00:00
pristine-tar data for snakemake_6.14.0.orig.tar.gz
- - - - -
2 changed files:
- + snakemake_6.14.0.orig.tar.gz.delta
- + snakemake_6.14.0
Rebecca N. Palmer pushed to branch master at Debian Med / snakemake
Commits:
1ee51741 by Rebecca N. Palmer at 2022-01-26T21:13:21+00:00
New upstream version 6.14.0
- - - - -
6dcfe9a3 by Rebecca N. Palmer at 2022-01-26T21:13:41+00:00
Update upstream source from tag upstream/6.14.0
Update
The issue turned out to be that the pandas repository's settings were
pointed to a CI settings file outside the repository, so it wasn't even
looking at my debian/salsa-ci.yml.
As suggested by Eriberto's link, this setting is found at (starting from
the repository's page in Salsa, logged in)
The default (I'm not sure if this is a global or per-team default) Salsa
CI pipeline tries to build and test packages on every commit.
For pandas, this always hits the 1 hour timeout, and hence "fails"
uselessly (wasting both the server's resources, and my attention when a
failure alert
Rebecca N. Palmer pushed new tag debian/6.12.3-1 at Debian Med / snakemake
--
View it on GitLab:
https://salsa.debian.org/med-team/snakemake/-/tree/debian/6.12.3-1
You're receiving this email because of your account on salsa.debian.org.
___
debian
Rebecca N. Palmer pushed to branch master at Debian Med / snakemake
Commits:
b21b17a1 by Rebecca N. Palmer at 2022-01-11T21:23:02+00:00
finalize for upload to unstable
- - - - -
1 changed file:
- debian/changelog
Changes:
=
debian/changelog
Rebecca N. Palmer pushed new tag upstream/6.12.3 at Debian Med / snakemake
--
View it on GitLab:
https://salsa.debian.org/med-team/snakemake/-/tree/upstream/6.12.3
You're receiving this email because of your account on salsa.debian.org.
___
debian
Rebecca N. Palmer pushed to branch upstream at Debian Med / snakemake
Commits:
48c2b38f by Rebecca N. Palmer at 2022-01-08T19:36:27+00:00
New upstream version 6.12.3
- - - - -
30 changed files:
- .github/workflows/conventional-prs.yml
- .github/workflows/main.yml
- CHANGELOG.md
- docs
Rebecca N. Palmer pushed to branch pristine-tar at Debian Med / snakemake
Commits:
4ed119e2 by Rebecca N. Palmer at 2022-01-08T19:36:46+00:00
pristine-tar data for snakemake_6.12.3.orig.tar.gz
- - - - -
2 changed files:
- + snakemake_6.12.3.orig.tar.gz.delta
- + snakemake_6.12.3
Rebecca N. Palmer pushed to branch master at Debian Med / snakemake
Commits:
89e5483e by Nilesh Patra at 2021-11-10T01:03:44+05:30
New upstream version 6.10.0+dfsg1
- - - - -
f5e50c2a by Rebecca N. Palmer at 2022-01-08T19:34:09+00:00
Remove unnecessary repack.
- - - - -
48c2b38f by Rebecca N
The statsmodels in unstable (though not testing) is already built
against sphinx 4.3, but this sounds like it might affect other packages.
Is that likely, and if so, what should we do about it?
After build-testing about half of the reverse dependencies, failures
that look new-pandas-related are cfgrib #1000726, joypy #1000727,
python-skbio #1000752, and maybe hyperspy (not filed yet).
python-skbio and hyperspy already FTBFS for unrelated reasons (but fail
more tests with new
After build-testing about half of the reverse dependencies, failures
that look new-pandas-related are cfgrib #1000726, joypy #1000727,
python-skbio #1000752, and maybe hyperspy (not filed yet).
python-skbio and hyperspy already FTBFS for unrelated reasons (but fail
more tests with new
Control: block 996584 by -1
On 21/11/2021 06:30, Graham Inggs wrote:
It might be easier to upgrade to 1.2.4 first, then 1,3,x later.
Probably not, given that we're now trying to add Python 3.10 support
(#996584), and pandas upstream's work on that is recent (maybe still
unfinished):
I was already planning to try a build+autopkgtest of the reverse
dependencies, and probably an upload to experimental (it's also common
for pandas to fail a few tests on non-amd64), at some point, but not
just yet. (The last time I did this was #969650.)
Thanks for the tools suggestions.
I
Source: pandas
Version: 1.1.5+dfsg-2
Severity: wishlist
On 10/11/2021 17:14, Andreas Tille wrote:
pandas is lagging behind upstream by several versions. I guess we
should try to get in sync with upstream a bit more.
Yes, but please don't upload this yet: it's common for a pandas upgrade
to
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
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
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
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.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Control: tags -1 patch
This looks similar to #997026, and the same fix appears to work.
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
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
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
On 18/10/2021 08:15, Nilesh Patra wrote:
On Mon, Oct 18, 2021 at 01:32:30AM +0200, Steffen Möller wrote:
Is anyone continuing the update of
snakemake now?
@Rebecca, could you look into it now that pulp is done?
Currently, there is just a very few failing tests -- I guess
most are due to some
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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,
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,
501 - 600 of 2394 matches
Mail list logo
