Control: tags -1 wontfix
Most of gpuocelot is not BSD but "BSD plus you must obey US export
restrictions (even if you are not in the US)" [0]. This is both
non-DFSG-free [1] and impractical for Debian to enforce, and is hence
not permitted even in non-free [2].
gpuocelot's authors have been
Control: retitle -1 ITA: theano -- CPU/GPU math expression compiler for
Python
As previously suggested[0], I intend to adopt this (and probably
libgpuarray as well, though that's not a promise at this point).
I am a debian-science team member, but not a DD.
Upstream just released 0.9; should
Control: merge -1 813809
I'd also like to see this (or an equivalent: I'm not aware of any, but
haven't looked much) in Debian, and am willing to try packaging it, but
am not sure whether it's a good idea for a non-DD,
non-security-specialist to maintain a security tool.
It's in Fedora, with
I haven't actually got around to doing anything with it, so go ahead.
On 01/10/17 08:38, Ghislain Vaillant wrote:
I thought Theano v0.9.x would require libgpuarray 0.7.x? Or is that for
the future (and probably last) 1.0 version?
The documentation for theano stable (0.9.0, this package) says 0.6.2:
http://www.deeplearning.net/software/theano/install_ubuntu.html#
They have now said libgpuarray 0.6 for Theano 0.9 (i.e. what we
currently have is fine) and libgpuarray 0.7 for Theano 0.10.
https://github.com/Theano/Theano/issues/6454
(#877316 is a separate problem.)
Control: retitle -1 ITP: pocl -- Portable OpenCL
(For those reading in the bug, my previous message is
http://lists.alioth.debian.org/pipermail/pkg-opencl-devel/Week-of-Mon-20140203/79.html
)
(importing and testing the pre 0.9
releases, ...)
I'll give that a try.
Would it make sense for
After importing version 0.9 and making the attached changes to /debian,
pocl builds, and appears to be functional (tested with pyopencl).
Remaining known issues:
Out-of-date symbols files (how do you get the (c++) in there?)
dpkg-shlibdeps warnings:
dh_shlibdeps -a -- --warnings=7
dpkg-shlibdeps
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.
Note that these are distinct:
- conda, the package manager itself; BSD-3 licensed
- Anaconda Individual Edition, a bundle of conda + some commonly-used
packages; non-DFSG-free as it includes intel-mkl and cudnn
(https://docs.anaconda.com/anaconda/eula/)
- Anaconda repository, the server conda us
Package: wnpp
Severity: wishlist
Owner: debian-...@lists.debian.org
X-Debbugs-Cc: debian-de...@lists.debian.org,debian-...@lists.debian.org
* Package name: python-snakemake-interface-common
(source; binary python3-snakemake-interface-common, and possibly
python-snakemake-interface-common-doc
Control: retitle -1 ITA: pagure - git-centred forge
As you may have noticed, I have been fixing several bugs in pagure.
I'm not yet sure whether it will be reasonably possible to get it into a
state that we want to keep, or whether I will end up deciding to remove it.
(The linked Fedora notic
On 02/01/2025 08:11, Rebecca N. Palmer wrote:
I'm not yet sure whether it will be reasonably possible to get [pagure] into a
state that we want to keep, or whether I will end up deciding to remove it.
My version in Salsa appears to be working except for plugins and
dump+reload, which is
Control: retitle -1 ITA: rpy2 -- Python3 interface to GNU R
I'm planning to work on this, possibly in debian-science.
Do you have any existing work on 3.6, and if so where? (Salsa looks
like you don't.)
15 matches
Mail list logo
