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
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
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
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
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
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
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
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 |
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'
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
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 |
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",
)
--
debian-science-maintainers mailing list
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
>
I am on it.
Cheers
- Le 12 Nov 23, à 8:06, Antonio Valentino antonio.valent...@tiscali.it a
écrit :
> Dear Frederic,
> I kindly ask your sponsor the initial upload of the c-blosc2 library.
> It is a compression library that in now (since PyTables v3.8) a
> dependency of the PyTables
Hello,
Do we have a cmd line tool which allows to extract the list of the source
package and the vcs-x info for a given maintainer or uploaders.
via udd (for an uptodate info)...
The idea is to generate a mrconfig file for a dedicated team instead of doing
it manually.
thanks
Frederic
--
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
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
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
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
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:
Hello,
I am preparing the cctbx[1] package and I am facing this issue. cctbx embed the
ann libbrary via this repository [2], but worst than that it also apply a
transformation to its source code
https://github.com/cctbx/annlib_adaptbx/blob/master/source_generators/generate_all.py
this produce
Hello, I removed the vtk7 dependency but I needed a bunch of -dev packages.
+ libavcodec-dev,
+ libavformat-dev,
libdouble-conversion-dev,
libfftw3-dev,
+ libfreetype-dev,
+ libgdal-dev,
libgdcm-tools,
+ libgl2ps-dev,
+ libglew-dev,
libinsighttoolkit4-dev,
liblz4-dev,
+ libogg-dev,
Hello anton,
If I try to switch to vtk9 it end up with
The following packages have unmet dependencies:
python3-paraview : Conflicts: python3-vtk9 but 9.1.0+really9.1.0+dfsg2-3+b3 is
to be installed
cheers
--
debian-science-maintainers mailing list
Done, it is now public
Cheers
Fred
- Antonio Valentino a écrit :
> Hi Andreas,
> the git repository for the triangle package on salsa
> (https://salsa.debian.org/science-team/triangle) seems to be private.
> Could you please make it public?
> The debian tracker complains about it and it
It seems that this is an issue in gcc has observed when compiling tensorflow
https://zenn.dev/nbo/scraps/8f1505e365d961
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
bugs report are already filled on matplotlib
#1000774 and #1000435
I will try to see if this is identical...
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
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
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
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
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
Hello, Jerome,
Due to the freeze, I think that the best solution is to do the backport.
I will add a patch to fabio and upload it.
thanks
Fred
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
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
--
debian-science-maintainers mailing list
Sorry I would have said antonio, it seems that the build failed on salsa ???
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Hello anton,
is it normal ?
https://salsa.debian.org/science-team/pysph/-/jobs/1420077
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
> Strangely enough, I've already done that ;-)
my bad.
Cheers
Fred
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
> 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
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 ?
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
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
--
debian-science-maintainers mailing list
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
you can look also at the CI, now that it works :)
https://salsa.debian.org/science-team/veusz/pipelines/137494
Cheers
Frederic
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
Yes it is not in buster but if you want to look at hdf5 files you can try silx
silx view foo.h5
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
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
À :
A work around for now is to install by hand
apt install python3-scipy
reassign -1 silx
thanks
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
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
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
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
--
debian-science-maintainers mailing list
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
-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 =
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
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
not better
test cpp engine for medfilt2d ... ok
testOpenCLMedFilt2d (silx.image.test.test_medianfilter.TestMedianFilterEngines)
test cpp engine for medfilt2d ... pocl error: lt_dlopen("(null)") or lt_dlsym()
failed with 'can't close resident module'.
note: missing symbols in the kernel binary
It seems that this test does not PASS
@unittest.skipUnless(ocl, "PyOpenCl is missing")
def testOpenCLMedFilt2d(self):
"""test cpp engine for medfilt2d"""
res = medianfilter.medfilt2d(
image=TestMedianFilterEngines.IMG,
Hello
>Package: sardana
>Version: 3.0.0a+3.f4f89e+dfsg-1
>Severity: serious
>The release team have decreed that non-buildd binaries cannot migrate to
>testing. Please make a source-only upload so your package can migrate.
ok, but this packages comes from NEW.
So it would be nice if the
> I didn't notice it, so wasn't planning to add it. spyder_kernels
> imports without complaining, and spyder seems to start fine anyway.
> Where does it come to notice?
I do not know, but on wndows it is optional.
So maybe this is not a big issue.
Fred
--
debian-science-maintainers mailing
It seems that wurlitzer which is a dependency of spyder-kernel is missing.
did you plan to add it ?
cheers
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Hello
> Hi Frédéric, I prepared spyder (and spyder-kernels) for python2 removal.
> The removal of cloudpickle forces us to do it earlier than we otherwise
> might have.
no problem for me :), the faster we get rid of Python2, the better.
> With spyder, it made sense to me to keep spyder as the
Ok this simple script trigger the bug.
from PyQt5.QtWidgets import QApplication, QLabel
app = QApplication([])
on KDE, but not on Gnome.
BUT this
app = QApplication(['a'])
works.
on KDE and Gnome.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
If I remove the config file, I have this error
picca@cush:~$ rm .config/silx/silx-view.ini
picca@cush:~$ silx view
QSettings::value: Empty key passed
QSettings::value: Empty key passed
KCrash: crashing... crashRecursionCounter = 2
KCrash: Application Name = python3.7 path = /usr/bin pid = 1893
Ok, I can reproduce this bug.
I switched to plasma and now I have
picca@cush:~$ silx view
malloc_consolidate(): invalid chunk size
KCrash: crashing... crashRecursionCounter = 2
KCrash: Application Name = python3.7 path = /usr/bin pid = 1876
KCrash: Arguments:
Minuterie d'alerte
So this is
Did you trye also to remove the .config files
picca@cush:~/.config/silx$ ls
silx-view.ini
If I remember correctly, I had a problem which was solved by removing this file.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
Here you have the information about the core dump.
https://wiki.debian.org/HowToGetABacktrace
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
> Please find attached the output
It seems that KCrash is in our way.
Is it possible for you to run silx view from a gnome environment ?
are you using kde ?
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
gdb -ex r --args python3 -m silx.app.view.main
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Hello carlos,
I am using this on all our computers and I have no problem.
com-diffabs@diffabs6:~$ dpkg -l | grep silx
ii python-silx 0.11.0+dfsg-1~bpo10+1
amd64Toolbox for X-Ray data analysis - Python2
library
ii
Hello, this is a probleme due to a bug in python-numpy which is already solved
in python-numpy 1.6.5
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933056
Cheers
De : debian-science-maintainers
> Hi,
> The latest pyFAI uses python3 for the application instead of python2,
> at least on the master. I did not check if it was the case for the release.
> In the worse case, one would just have to wait for the next release
> which is planed later this year. Anyhow, I recently fixed a bug
Is it a leaf package ?
De : debian-science-maintainers
[debian-science-maintainers-bounces+picca=synchrotron-soleil...@alioth-lists.debian.net]
de la part de Debian FTP Masters [ftpmas...@ftp-master.debian.org]
Envoyé : mercredi 28 août 2019 12:43
À :
is the version number correct.
I thought that stretch-backports-sloppy would be bpo9 and not bpo10.
I missed something ?
Fred
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
Hello,
I am wondering if the problem is not a gcc bug.
I tryed to deal with this issue, with the ccan upstream.
https://github.com/rustyrussell/ccan/issues/65
but I do not have the skills in order to fix it otherwise than applying the
simple one line fix
Here the patch I am applying i order
This regression is due to a bug in python-numpy #933056, that I already
reported, whcih was solved upstream and will be available in the 0.17 version.
Cheers
Fred
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
The upstream, Just packages the latest taurus.
So I think that you can defer your upload now.
thanks a lot for your help.
Frederic
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
Hello, here an answer from the ESRF.
De : V. Armando Sole [s...@esrf.fr]
Envoyé : mercredi 23 janvier 2019 20:29
À : PICCA Frederic-Emmanuel
Cc : s...@edna-site.org
Objet : Re: Fw: TR : Bug#920257: python3-fabio: program fails with Nexus data
from Diamond
Hello Carlos,
> I am fine with removing it, but just let me point that if it does not cause
> harm to leave it there, it may facilitate the creation of backports to
> stretch.
I think that it needs to be removed for Buster.
I understand for the backports.
do you know if a release is expected
Hello,
since Debian wants to remove python-qt4 for buster, maybe it would be nice to
remove this from the dependecies ?
Do not hesitate to commit this change if this is ok for you.
Fred
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
Hello Marc, do you have an account on salsa.debian.org.
This way you could fix directly the problem on the Debin package :)).
Tell me if you need help.
Fred
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
Hello Adrian
If I look at the current boost1.67, I find this in the
boost python package
https://packages.debian.org/sid/amd64/libboost-python1.67.0/filelist
and
https://packages.debian.org/sid/amd64/libboost-python1.67-dev/filelist
We can find these
> Ok, I did it. It is right?
It would be nice to hqve q one line explqinqtion of the fix.
sort of
d/tango-starter.init.d
-Added network to Should-[Start|Stop]. (Closes: #...)
It is important to have something understandable in the debian changelog.
thansk
Fred
Ps: What about the patch
Hello carlog
> I think so, It may affect to others users.
So is it possible to add this as a patch for the packaging ?
> I did a MR (https://salsa.debian.org/science-team/tango/merge_requests/1)
Can you modify your MR and update the Debian/changelog in order to close the
bug during the next
Hello Carlos,
> Dear Maintainer,
> We saw that in some machines the tango-starter did not start after
> rebooting the PC.
> Note: We are using a custom version of the tango package (
> 9.2.5a+dfsg1-2+patch1~bpo9+0~alba+1)
is this patch interesting for others ?
> # Should-Start: tango-db
Hello guyes,
I would like to know if you are ok, if I grant a Developer acces to
salsa-pipeline-guest for the science-team.
I would like to use this [1], for my packages.
what is your opinion ?
thanks
Frederic
[1] https://salsa.debian.org/salsa-ci-team/pipeline
--
debian-science-maintainers
> your autopkg tests loops over all *supported* python versions, but you only
> build the extension for the *default* python3 version. Try build-depending on
> python3-all-dev instead and see that you have extensions built for both 3.6
> and
> 3.7. Building in unstable, of course.
But , I
Hello, Matthias,
I do not understand this bug report.
I use pybuild so fabio should be build for all python3 versions.
It is now FTBFS due to a problem with the cython package already reported.
#903909
Cheers
Frederic
--
debian-science-maintainers mailing list
It seems to me that the real culprite is python-numpy.
De : debian-science-maintainers
[debian-science-maintainers-bounces+picca=synchrotron-soleil...@alioth-lists.debian.net]
de la part de Paul Gevers [elb...@debian.org]
Envoyé : samedi 12 mai 2018
there is two problemes.
kiwisolver MUST provide -dbg packages AND matplotlib should depends on these
packages once available.
Cheers
Frederic
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
89 matches
Mail list logo
