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
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'
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 |
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 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
>
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()
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
> 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
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
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:
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
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
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
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
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
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
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
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
> 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]
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
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
À :
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
-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,
Use salsa-ci, python-qtconsole FTBFS due to pyzmq
https://salsa.debian.org/python-team/modules/python-qtconsole/-/jobs/435758
Hello,
I am packaging jupyter_sphinx whcih is a dependency of the new lmfit-py.
But it required at least ipywidgets > 7.
Do you plan to upload this new version into Debian ?
thanks for considering
You are right, the file was downloaded from github, and files gives,
picca@cush:~/Debian/tango$ file tango-9.3.4-rc2.tar.gz
tango-9.3.4-rc2.tar.gz: gzip compressed data, from FAT filesystem (MS-DOS,
OS/2, NT), original size 284221440
once repack with tar
picca@cush:~/Debian/tango$ file
> Last I checked nobody filed a bug against tar, please do so if you wish.
Isn't it better if this bug was reassign to tar ?
Cheers
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
It seems that wurlitzer which is a dependency of spyder-kernel is missing.
did you plan to add it ?
cheers
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
Is it possible to fix Buster ?
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.
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
1 - 100 of 330 matches
Mail list logo
