thanks a lot, it is ok with this NMU, you can also commit to the git repositoy
if you want :).
https://salsa.debian.org/science-team/ifeffit
Cheers
Fred
Is it possible to make it binNMUable ?
Fred
- Le 14 Jan 25, à 13:20, Emilio Pozuelo Monfort po...@debian.org a écrit :
> Package: pyvkfft-cuda
> Version: 2024.1.4+ds1-4
> Severity: serious
>
> Hi,
>
> The ongoing python3.13 as python3 interpreter causes your package to be
> uninstallable,
Hello hkl and hs-hdf5 upstream here.
I can reproduce and see that the current hkl code is not compatible with the
haskell-hdf5 recompile with hdf 1.14.
This is something which should be solved at the hs-hdf5 level.
Build profile: -w ghc-9.6.6 -O1
In order, the following will be built (use -v fo
- Le 17 Sep 24, à 20:02, Mechtilde Stehmann mechti...@debian.org a écrit :
> Package: wnpp
> Severity: wishlist
> Owner: Mechtilde Stehmann
> X-Debbugs-Cc: debian-de...@lists.debian.org, mechti...@debian.org
>
> * Package name: webext-folder-account
> Version : 12.0
> Upstre
> That is true. I don't consider the bug to be the use of a temporary
> directory,
> but instead the embedding of build paths. I'll do some more investigation to
> try to figure out whether that can be resolved within the build toolchain.
thanks
> It appears my fix here is incomplete or inaccu
> The meson-python build generates and uses a temporary, randomized build
> directory path only when no build-dir setting is already configured. So we
> may
> be able to resolve this problem by choosing an appropriate static build-dir.
why not fixing meson-python directly. This way it is simp
If you are part of the Debian science just push to the repository.
It is easyer for me to revert from git, than to remember to check for MR :)
thanks a lot for these investigation.
it is very appreciable
Frederic
- Le 9 Aoû 24, à 13:18, James Addison via Debian-pan-maintainers
debian-p
Hello, I am the facet-analyser maintainer/upstream (support)
If fact the conflict comes from
facet-analyser -> libinsighttoolkit5-dev -> lib-vtk9-dev -> python3-vtk9
facet analyser which is a PV plugins depends also on paraview-dev.
facet-analyser -> paraview-dev -> conflict with python3-vt
the packaging of the next version is done here
https://salsa.debian.org/js-team/node-jupyterlab
in the branch merge-python-and-node
to build it
git clone -b merge-python-and-node
https://salsa.debian.org/js-team/node-jupyterlab
and
cd node-jupyterlab
gbp buildpackage --git-ignore-branch \
Running the upstream script I have this
$ bash ./ci_script.sh
+ set -o pipefail
+ export YARN_ENABLE_GLOBAL_CACHE=1
+ YARN_ENABLE_GLOBAL_CACHE=1
+ export YARN_ENABLE_INLINE_BUILDS=1
+ YARN_ENABLE_INLINE_BUILDS=1
+ [[ '' != nonode ]]
+ python -c 'from jupyterlab.commands import build_check; buil
Here the upstream point of view about the CVE.
https://github.com/epics-base/epics-base/issues/405
check with the security team, if their analyse is ok ?
Fred
Here the diff between the epics version (debian patch unapplyed) and the
current 2.1.0 version of yajl (debian patch unapplyed).
not that simple...diff --git a/src/yajl.c b/src/yajl.c
index d477893..fdad3f6 100644
--- a/src/yajl.c
+++ b/src/yajl.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2007-2014,
following a different path...,
I added this in the rules file
-export POSIX_CFLAGS+=$(CFLAGS)
+export POSIX_CFLAGS+=$(CFLAGS) $(shell pkgconf --cflags yajl)
export POSIX_CFLAGS+=$(CPPFLAGS)
export POSIX_CPPFLAGS+=$(CPPFLAGS)
-export POSIX_LDFLAGS+=$(LDFLAGS)
+export POSIX_LDFLAGS+=$(LDFLAGS) $(sh
I am working on it at the upstream level
need a few more days.
Cheers
Fred
Hello Andreas,
I have another autopkgtest failure on armel with silx and pocl
The content of check_atomic32 is
def check_atomic32(device):
try:
ctx = pyopencl.Context(devices=[device])
except:
return False, f"Unable to create context on {device}"
else:
queue
bravo !!!
This is team works. :))
Cheers
Frederic
Here an analyse of the FTBFS
On the amd64, I have two failures dureing the test
Test Summary Report
---
testPVAServer.t(Wstat: 0 Tests: 0 Failed: 0)
Parse errors: No plan found in TAP output
Files=6, Tests=129, 1 wallclock secs ( 0.05 usr 0.01 sys + 0.09 cusr 0.06
csys
A workaround for now is to use this
POCL_WORK_GROUP_METHOD=cbs
Jerome is helping also here trying to understand the problem...
https://github.com/silx-kit/silx/issues/4073
POCL_WORK_GROUP_METHOD=cbs python3 test.py
make it works
$ POCL_WORK_GROUP_METHOD=cbs python3 test.py
[SubCFG] Form SubCFGs in bsort_all
[SubCFG] Form SubCFGs in bsort_horizontal
[SubCFG] Form SubCFGs in bsort_vertical
[SubCFG] Form SubCFGs in bsort_book
[SubCFG] Form SubCFGs in bsort_file
[SubC
With latest version (PAS OK)
$ dpkg -l | grep pocl
ii libpocl2-common5.0-2.1
all common files for the pocl library
ii libpocl2t64:amd64 5.0-2.1
amd64
Debian12 (OK)
$ dpkg -l | grep pocl
ii libpocl2:amd64 3.1-3+deb12u1
amd64Portable Computing Language library
ii libpocl2-common 3.1-3+deb12u1
all co
On Debian12 it works out of the box
$ POCL_DEBUG=1 python3 test.py
[2024-03-11 10:05:31.837738936]POCL: in fn pocl_install_sigfpe_handler at line
229:
| GENERAL | Installing SIGFPE handler...
[2024-03-11 10:05:31.868890390]POCL: in fn POclCreateCommandQueue at line 98:
| GENERAL | Crea
We already had the warning message
[2024-03-10 14:26:18.189651850]POCL: in fn void
appendToProgramBuildLog(cl_program, unsigned int, std::string&) at line 111:
| ERROR | warning:
/home/picca/.cache/pocl/kcache/tempfile_msXjLw.cl:861:14: AVX vector argument
of type '__private float8' (vec
Here a log with POCL_DEBUG=all
picca@cush:/tmp$ python3 test.py
[2024-03-10 14:22:19.462191847]POCL: in fn pocl_install_sigfpe_handler at line
265:
| GENERAL | Installing SIGFPE handler...
[2024-03-10 14:22:19.475550217]POCL: in fn POclCreateCommandQueue at line 103:
| GENERAL | Create
It seems that here is an error here
[2024-03-10 14:22:19.550588408]POCL: in fn int
pocl_llvm_build_program(cl_program, unsigned int, cl_uint, _cl_program* const*,
const char**, int) at line 420:
| LLVM | all build options: -Dcl_khr_int64
-DPOCL_DEVICE_ADDRESS_BITS=64 -D__USE_CLANG_OPENC
Here a small script which trigger the errorfrom silx.image import medianfilter
import numpy
IMG = numpy.arange(1.0).reshape(100, 100)
KERNEL = (1, 1)
res = medianfilter.medfilt2d(
image=IMG,
kernel_size=KERNEL,
engine="opencl",
)
In order to reproduce the bug,
install python3-silx 2.0.0+dfsg-1
python3-pytest-xvfb pocl-opencl-icd
then
$ pytest --pyargs silx.image.test.test_medianfilter -v
===
test session starts
With the silx 2.0.0 version the failire is located in the OpenCL part
the backtrace is this one when running the median filter
# build the packag eintht echroot and enter into it once build
dgit --gbp sbuild --finished-build-commands '%SBUILD_SHELL'
run this command to obtain the backtrace...
for dials it seems that the CI works with pandas 2.1 from experimental.
https://ci.debian.net/packages/d/dials/unstable/amd64/41962612/#S4
- Le 30 Jan 24, à 9:05, Rebecca N. Palmer rebecca_pal...@zoho.com a écrit :
> I intend to upload pandas 2.x to unstable soon. These packages have a
> p
ok for me
- Le 4 Jan 24, à 13:19, Alexandre Detiste alexandre.deti...@gmail.com a
écrit :
> Le jeu. 4 janv. 2024 à 07:48, Andreas Tille a écrit :
>> > @Vincent: this one package "gtextfsm" is yours
>> > do you green light an upload ?
>>
>> If you ask me the package is team maintained and a
It seems to me that the FTBFS was not due to cython 3.x but related to this bug
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054716
now that this bug is solved, can you re run the build for bitshuffle ?
Frederic
Hello, here you should find the informations.
platform: Debina unstable
python: ~$ python3
Python 3.11.5 (main, Aug 29 2023, 15:31:31) [GCC 13.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>
$ dpkg -l | grep wx
ii libwxbase3.2-1:amd64
Hello, I am preparing the packaging of genx 3.6.22.
When I try to quit the application I have this error message
CRITICAL: uncought python error
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/genx/gui/main_window.py", line 1418, in
eh_mb_quit
if event.CanVeto() and
the old and new hyperspy is not compatible with imagio > 0.28.
I kindly opened a bug report about the situation at the upstream git repository.
I filled a bug report about the new upstream.
https://github.com/g1257/dmrgpp/issues/40
It is already fixed in the upstream git
https://github.com/g1257/dmrgpp/commit/528501e4a5814d4cbb80e2cf16ea407f9e012ee6
and a comment about this issue
https://github.com/g1257/dmrgpp/issues/38#issuecomment-1655740289
Hello,
I dicovered that upstream modifier yajl in order to support json5.
I am wondering if their modification could not be integrated in our yajl.
I fill a burg report about this idea here
https://github.com/epics-base/epics-base/issues/405
Tell me what is your opinion about this.
Cheers
Fre
> I am just the messenger here, if you disagree, please feel free to
> contact ftpmasters or lintian maintainers.
This was not a rant about this, I just wanted to understand what is going on :).
> Your package has been built successfully on (some) buildds, but then the
> binaries upload got rejec
I just check this date is in the upstream tar file
https://files.pythonhosted.org/packages/54/84/ea12e176489b35c4610625ce56aa2a1d91ab235b0caa71846317bfd1192f/pyfai-2023.5.0.tar.gz
ok, it seems that I generated an orig.tag.gz with this (Thu Jan 1 00:00:00
1970).
I can not remember which tool I used to generate this file.
gbp import-orig --uscan
or
deb-new-upstream
Nevertheless, why is it a serious bug ?
thanks
Frederic
If I remove the pylint package, no more error...
There is a fix from the upstream around enum.
https://github.com/boostorg/python/commit/a218babc8daee904a83f550fb66e5cb3f1cb3013
Fix enum_type_object type on Python 3.11
The enum_type_object type inherits from PyLong_Type which is not tracked
by the GC. Instances doesn't have to be tracked by
in order to debug this, I started gdb
set a breakpoint in init_module_scitbx_linalg_ext
then a catch throw and I end up with this backtrace
Catchpoint 2 (exception thrown), 0x770a90a1 in __cxxabiv1::__cxa_throw
(obj=0xb542e0, tinfo=0x772d8200 , dest=0x772c1290
) at
../../../..
Hello Anton, I have just pushed a few dependencies in the -dev package in the
salsa repo
I did not updated the changelog.
Cheers
Fred
Hello Anton, I try to checkout paraview in order to add the -dev dependencies
but I have this message
$ git clone https://salsa.debian.org/science-team/paraview
Clonage dans 'paraview'...
remote: Enumerating objects: 175624, done.
remote: Counting objects: 100% (78929/78929), done.
remote: Compre
Hello François,
thanks a lot, I removed the NMU number and release a -2 package. (uploaded)
thanks for your contribution to Debian.
Fred
It seems that it failing now
https://ci.debian.net/packages/p/pyfai/
I am on 0.21.2 but I do not know if it solve this mask issue.
Cheers
Fred
Hello Paul, just for info, I have already reported this issue here
https://github.com/g1257/dmrgpp/issues/38
cheers
Fred.
Is it not better to use the
DEB__MAINT_APPEND
variable in order to deal with this issue ?
It seems that this is an issue in gcc has observed when compiling tensorflow
https://zenn.dev/nbo/scraps/8f1505e365d961
Built with gcc-11 and -fno-lto it doesn not work.
(sid_mips64el-dchroot)picca@eller:~/matplotlib/build/lib.linux-mips64-3.9$
../../../test.py
Segmentation fault
(sid_mips64el-dchroot)picca@eller:~/matplotlib/build/lib.linux-mips64-3.9$
PYTHONPATH=. ../../../test.py
Segmentation fault
I tested matplotlib built with numpy 0.17 0.19 0.21. each time I got the
segfault.
another difference was the gcc compiler.
So I switched to gcc-10
(sid_mips64el-dchroot)picca@eller:~/matplotlib$ CC=gcc-10 python3 setup.py build
if failed with this error
lto1: fatal error: bytecode stream in
If I run in the sid chroot, but with the binaryed built from bullseye, it works.
(sid_mips64el-dchroot)picca@eller:~/matplotlib-3.5.0/build/lib.linux-mips64-3.9$
rm toto.png
(sid_mips64el-dchroot)picca@eller:~/matplotlib-3.5.0/build/lib.linux-mips64-3.9$
python3 test.py
(sid_mips64el-dchroot)p
Here no error during the build of numpy 1.19.5
= 10892 passed, 83 skipped, 108 deselected, 19 xfailed, 2 xpassed, 2 warnings
in 1658.41s (0:27:38) =
but 109 for numpy 1.21...
= 14045 passed, 397 skipped, 1253 deselected, 20 xfailed, 2 xpassed, 2
warnings, 109 errors in 869.47s (0:14:29) =
I investigated a bit more, it seems that cover is wrong.
In a bullseye chroot it works
$ python3 ./test.py
(bullseye_mips64el-dchroot)picca@eller:~/matplotlib-3.5.0/build/lib.linux-mips64-3.9$
ls
matplotlib mpl_toolkits pylab.py test.py toto.png
I found that the test failed between the 3.3
the full python backtrace
#8
#14 Frame 0x120debd80, for file
/home/picca/matplotlib-3.5.0/build/lib.linux-mips64-3.9/matplotlib/lines.py,
line 2888, in draw (self=,
figure=<...>, _transform=None, _transformSet=False, _visible=True,
_animated=False, _alpha=None, clipbox=None, _clippath=None, _
Here the py-bt
(gdb) py-bt
Traceback (most recent call first):
File
"/home/picca/matplotlib-3.5.0/build/lib.linux-mips64-3.9/matplotlib/lines.py",
line 2888, in draw
File
"/home/picca/matplotlib-3.5.0/build/lib.linux-mips64-3.9/matplotlib/artist.py",
line 50, in draw_wrapper
return
I can confirm that the bullseye matplotlib does not produce a segfault
This small script trigger the segfault.
#!/usr/bin/env python3
import matplotlib
import matplotlib.pyplot as plt
plt.figure()
plt.title("foo")
plt.savefig("toto.png")
bugs report are already filled on matplotlib
#1000774 and #1000435
I will try to see if this is identical...
Here the backtrace on mips64el
#0
agg::pixfmt_alpha_blend_rgba,
agg::order_rgba>, agg::row_accessor >::blend_solid_hspan(int,
int, unsigned int, agg::rgba8T const&, unsigned char const*)
(covers=0x100 , c=..., len=, y=166, x=,
this=)
at extern/agg24-svn/include/agg_color_rg
Hello
reading this I do not understand what need to be changed in the init script
https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
Whenever systemd encounters a $network dependency in LSB headers of init
scripts it will translate this to a Wants= and After= dependency on
networ
ack ;)
sorry for the delay.
You can commit directly to the repository.
Cheers
Fred
De : Benda Xu [o...@debian.org]
Envoyé : vendredi 24 septembre 2021 10:24
À : Anton Gladky
Cc : 994...@bugs.debian.org; PICCA Frederic-Emmanuel
Objet : Re: Bug#994882
Hello,
why there is no pkgconfig files provided with metis and metis64.
this simplify the configuration of packages depending on these libraries.
Cheers
Fred
lspci -tnnkv
lspci
Description: lspci
$ lspci -t
-+-[:e0]-+-00.0
| +-00.2
| +-01.0
| +-02.0
| +-03.0
| +-03.2-[e1-e2]--+-00.0
| | \-00.1
| +-04.0
| +-05.0
| +-07.0
| +-07.1-[e3]--+-00.0
| |
Source: linux
Severity: normal
Dear Maintainer,
For futher information, you can have a look here
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986312
this bug makes it impossible to use all the graphical cards in my computer.
The computer contain 2 kinds of graphicalcards 3 x RTX 3090 and 6
Hello Andrius.
I am on it, I am also the upstream of this software :)).
Thanks for your help, nevertheless I am a bit like you, I did not wrote this
part of the code :))
and the matplotlib changelog is sort of useless :))
Cheers
Fred
I have also this information in the syslog
Mar 29 08:01:51 re-grades-01 kernel: [1.762583] pci :42:04.0: BAR 15:
no space for [mem size 0x13800 64bit pref]
Mar 29 08:01:51 re-grades-01 kernel: [1.762584] pci :42:04.0: BAR 15:
failed to assign [mem size 0x13800 64bit pref]
Hello andreas
> what's the NUMA layout of the machine? what cpus do you have in there?
I attached the lstopo output.
> Great. Half of the bus ids are in hex, half in decimal.
> How many cards do you have in there? And how many pci devices are there
> per card?
the list is in the reportbug :)
> Strangely enough, I've already done that ;-)
my bad.
Cheers
Fred
> I have a package of Spyder 4 waiting to upload, but it requires five
> packages to be accepted into unstable from NEW first (pyls-server,
> pyls-black, pyls-spyder, abydos, textdistance); once that happens, the
> rest of the packages are almost ready to go.
Maybe you can contact the ftpmaster te
Ok, in that case, I think that a comment in the d/rules files is enough in
order to keep in mind that we have this issue with ppc64el.
> Well, the test is obviously broken and upstream currently can't be bothered
> to fix
> it on non-x86 targets. He will certainly have to do it at some point given
> that ARM64
> is replacing more and more x86_64 systems, but I wouldn't bother, personally.
so what is the best solution in order t
> Yes, good catch. The spec file for the openSUSE package has this [1]:
so it does not fit with our policy: do not hide problems ;)
The problem is that I do not have enougt time to investigate... on a porter box
Hello
looking at the Opensuze log, I can find this
[ 93s] + pytest-3.8 --ignore=_build.python2 --ignore=_build.python3
--ignore=_build.pypy3 -v -k 'not speed and not (test_model_nan_policy or
test_shgo_scipy_vs_lmfit_2)'
[ 97s] = test session starts
Hello Andreas,
I just built ghmm by removing --with-gsl.
It seems that the gsl implementation of blas conflict with the one provided in
atlas.
so --enable-gsl + --enable-atlas seems wrong...
+--+
| Summary
Hello,
We maintain a Debian blends dedicated to photo and neutron facilities
DebianPAN[1] via a dedicated team on salsa[2]
do not hesitate to tell me in which category[2] you think density-fitness
belongs
cheers
Frederic
[2] https://salsa.debian.org/pan-team
[1] https://salsa.debian.org/blen
Looking at the build log of pyfai, I can find this
https://launchpadlibrarian.net/501584970/buildlog_ubuntu-groovy-armhf.pyfai_0.19.0+dfsg1-3build1_BUILDING.txt.gz
Selecting previously unselected package python3-silx.
Preparing to unpack .../238-python3-silx_0.13.1+dfsg-1_armhf.deb ...
Unpacking
Hello, the error comes from here.
> ModuleNotFoundError: No module named 'silx.image.marchingsquares._mergeimpl'
did you rebuilt it with a silx packages already rebuilt with python3.9 ?
Hello,
It compile fine :), but I have a concern about the license.
It is considère a good practice to use the same license for the debian
directory and the source code.
In your case, you chooses GPL-3+, but the code is MIT.
Fred
Hello Thomas,
I am wondering if this is not a false positive.
all the code is compiled with -D_FORTIFY_SOURCE=2
https://salsa.debian.org/science-team/tango/-/jobs/954394/raw
Can you confirm that it is a false positive ?
I am not that confident when it comes to hardening flags.
for the record
I tryed a new build and I end up with this error
gpgv: unknown type of key resource 'trustedkeys.kbx'
gpgv: keyblock resource '/tmp/dpkg-verify-sig.Wwlhs1jL/trustedkeys.kbx':
General error
gpgv: Signature made Mon Dec 16 20:17:19 2019 UTC
gpgv:using RSA key E8FC295C86B8D7C049F97BA
did you started from here ?
https://salsa.debian.org/science-team/geant4
cheers
Frederic
you can look also at the CI, now that it works :)
https://salsa.debian.org/science-team/veusz/pipelines/137494
Cheers
Frederic
OK, with the previous NMU it works, so we can unbrand without problem the lzf
library
I am not sure at all of this in fact I red this closed bug
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955456
I discovered that the NMU was not included in the git repository.
Hello, I tryed to unbrand the lzf library but it end up with failing unit tests
I do not know the internals of liblzf.
Timo Röhling can you have a look at this issue ?
Cheers
Frederic
It seems that the embeded version of lzf and the one from your liblzf package
are different.
test_filter (
Done :))
sorry for the delay
De : Timo Röhling [t...@gaussglocke.de]
Envoyé : samedi 25 avril 2020 14:06
À : PICCA Frederic-Emmanuel
Cc : 956...@bugs.debian.org
Objet : Re: pkg-config for Qhull
Hi Frédéric!
On 12.04.20 14:22, PICCA Frederic-Emmanuel
Do you provide a pkgconfig file with qhull ?
De : debian-science-maintainers
[debian-science-maintainers-bounces+picca=synchrotron-soleil...@alioth-lists.debian.net]
de la part de Timo Röhling [t...@gaussglocke.de]
Envoyé : samedi 11 avril 2020 19:08
À : s
A work around for now is to install by hand
apt install python3-scipy
reassign -1 silx
thanks
Hello, I just want to know what is the status of this backport ?
thanks
Frederic
Hello, if it is like for my ufo-core package, this could be due to a script
file with a shebang using python instead of python3
Cheers
Fred
Maybe this is due to this
picca@cush:~/Debian/ufo-core/ufo-core/bin$ rgrep python *
ufo-mkfilter.in:#!/usr/bin/python
ufo-prof:#!/usr/bin/env python
I will replace python -> python3 and see what is going on
Hello Sandro this is strange because, I have this in the control file
Package: libufo-bin
Architecture: any
Depends: ${misc:Depends}, ${python3:Depends}, ${shlibs:Depends}
Suggests: ufo-core-doc
Description: Library for high-performance, GPU-based computing - tools
The UFO data processing framewo
-lists.debian.net]
de la part de Andreas Tille [andr...@an3as.eu]
Envoyé : dimanche 22 décembre 2019 10:48
À : PICCA Frederic-Emmanuel
Cc : 943...@bugs.debian.org; MARIE Alexandre
Objet : Bug#943786: lmfit-py: failing tests with python3.8
On Sun, Dec 22, 2019 at 07:54:23AM +, PICCA Frederic-Emmanuel
Hello andreas, In fact we were wayting for the pacakging of ipywidget 7.x
the jupyter-sphinx extension expected by lmfit-py require a newer version of
ipywidget.
So maybe the best solution for now is to not produce the documentation until
this dependency is ok.
cheers
Frederic
looking in picca@sixs7:~/Debian/silx/silx/silx/opencl/test/test_addition.py
def setUp(self):
if ocl is None:
return
self.shape = 4096
self.data = numpy.random.random(self.shape).astype(numpy.float32)
self.d_array_img = pyopencl.array.to_device(self.q
I decided to concentrate myself on one opencl test (addition)
So I deactivated all other test by commenting the test in
silx/opencl/__init__.py
If I do not import silxs.io, this test works
(sid_amd64-dchroot)picca@barriere:~$ PYOPENCL_COMPILER_OUTPUT=1
PYTHONPATH=silx-0.11.0+dfsg/.pybuild/cpyth
With the silx.io import I have this
(sid_amd64-dchroot)picca@barriere:~$
PYTHONPATH=silx-0.11.0+dfsg/.pybuild/cpython3_3.7_silx/build python3 test.py
pocl error: lt_dlopen("(null)") or lt_dlsym() failed with 'can't close resident
module'.
note: missing symbols in the kernel binary might be repo
1 - 100 of 343 matches
Mail list logo
