Package: cambalache
Version: 0.94.1-2
Followup-For: Bug #1095742
Dear Maintainer,
$ cambalache pseudo-4.ui
Traceback (most recent call last):
File "/usr/bin/cambalache", line 42, in
from cambalache.app import CmbApplication
File "/usr/lib/python3/dist-packages/cambalache/__init__.py",
With the upload of the new zarr, the errors are now
=== short test summary info
FAILED xarray/tests/test_groupby.py::test_dask_da_groupby_quantile - Failed: ...
FAILED
xarray/tests/test_weighted.py::test_weighted_operations_keep_attr[False-Tr
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
Hello Andreas,
you can fill an RM request. I think also that I do not have any time for
this software which I do not use anymore myself... I switched to
haskell ;).
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,
for more details):
- hkl-0.1.0.2 (lib) (first run)
- hkl-0.1.0.2 (exe:binoculars-ng) (first run)
Preprocessing library for hkl-0.1.0.2..
Building library for hkl-0.1.0.2..
[18 of 36] Compiling Hkl.H5 ( src/Hkl/H5.hs,
/home/picca/src/repo.or.cz/hkl/binoculars-ng/dist-newstyle/build/x86_64
Hello Jose Luis,
is it possible to solve this bug in order to avoid a bunch of reverse
dependency removal.
thanks a lot
Frédéric-Emmanuel
I am working on it at the upstream level
need a few more days.
Cheers
Fred
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
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 '__priva
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
111:
| ERROR | warning:
/home/picca/.cache/pocl/kcache/tempfile_NcEztR.cl:861:14: AVX vector argument
of type '__private float8' (vector of 8 'float' values) without 'avx' enabled
changes the ABI
warning: /home/picca/.cache/pocl/kcache/tempfile_NcEztR.cl:893:14: AVX v
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",
)
===
platform linux -- Python 3.11.8, pytest-8.0.2, pluggy-1.4.0 -- /usr/bin/python3
cachedir: .pytest_cache
rootdir: /home/picca/debian/science-team/pyvkfft
plugins: anyio-4.2.0, dials-data-2.4.0, xvfb-3.0.0
collected 2
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...
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.
and a comment about this issue
https://github.com/g1257/dmrgpp/issues/38#issuecomment-1655740289
close 1042214 4.4.1-1
thanks
solver with a previous upload
> 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
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
../../../..
To reproduce the problem
Python3.10:
:~/$ python3.10
Python 3.10.8 (main, Nov 4 2022, 09:21:25) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
import scitbx_linalg_ext
Python3.11
:~/$ python3.11
Python 3.11.0+ (main, Nov 4 2022, 09:23:33) [GC
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
46] Object does
not exist on the server or you don't have permissions to access it: [404]
Object does not exist on the server or you don't have permissions to access it
Errors logged to
/home/experiences/instrumentation/picca/debian/science-team/paraview/.git/lfs/logs/20221101T101535.4
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
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, _clippat
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 dra
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
here the backtrace
Type "apropos word" to search for commands related to "word"...
Reading symbols from numptyphysics...
Reading symbols from
/usr/lib/debug/.build-id/1c/669beb5cdc6578b37b1e53e575baefe21524ff.debug...
(gdb) r
Starting program: /usr/games/numptyphysics
[Thread debugging using li
Package: numptyphysics
Version: 0.2+svn157-0.4
Severity: grave
X-Debbugs-Cc: pi...@debian.org
the prgram do not start and crash at startup
-- System Information:
Debian Release: bullseye/sid
APT prefers stable-debug
APT policy: (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500,
> 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
Let's downgrad severity, only one test does not fail and the patform
are not supported by the upstream.
I prefer to have feedback of the autopkgtest in order to follow the
evolution of this issue.
severity 976952 normal
thanks
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
close 957430 6.5.1-3
thanks
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
Source: haskell-tree-monad
Severity: critical
Hello,
this package does not build with the up-comming ghc 8.8 version.
It is not part of stackage LTS, and it was not updated by upstream since 2009.
It means that there is few chance to see the upstream fix this issue.
so it is considere to remove
you can look also at the CI, now that it works :)
https://salsa.debian.org/science-team/veusz/pipelines/137494
Cheers
Frederic
A work around for now is to install by hand
apt install python3-scipy
reassign -1 silx
thanks
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
Hello andreas,
I will try to find some time during these holydays in order to upload the 1.0.0
version :)
cheers
Fred and happy new year.
De : debian-science-maintainers
[debian-science-maintainers-bounces+picca=synchrotron-soleil...@alioth
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
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
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 t
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 mig
or: lt_dlopen("(null)") or lt_dlsym()
failed with 'can't close resident module'.
note: missing symbols in the kernel binary might be reported as 'file not
found' errors.
Aborted
E: pybuild pybuild:341: test: plugin custom failed with: exit code=134: env
PYTHONPATH=/
Use salsa-ci, python-qtconsole FTBFS due to pyzmq
https://salsa.debian.org/python-team/modules/python-qtconsole/-/jobs/435758
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 proces
> 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 m
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
[debian-science-maintainers-bounces+picca=synchrotron
thanks a lot both of you, I could not manage to find enought time these days
for this package...
Cheers
Fred
The upstream, Just packages the latest taurus.
So I think that you can defer your upload now.
thanks a lot for your help.
Frederic
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
/usr/lib/x86_64-linux-gnu/libboost_python
looking at the fedora project they renames async -> async_
https://koji.fedoraproject.org/koji/buildinfo?buildID=1097515
In code search I found another package affected by this problem.
Which seems to embed pyOpenGL.
https://codesearch.debian.net/search?q=OpenGL.raw.GL.SGIX.async&perpkg=1
Cheers
looking at the fedora project they renames async -> async_
https://koji.fedoraproject.org/koji/buildinfo?buildID=1097515
> 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 alrea
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
This problem was due to this
python-fabio (0.5.0+dfsg-2) unstable; urgency=medium
* d/control
- python-qt4 -> python3-pyqt4-dbg (Closes: #876288)
Now that python-fabio was solved, it is ok to close this bug
thanks
Frederic
here the error message
~/Debian/nexus/bugs$ ./bug.py
Traceback (most recent call last):
File "./bug.py", line 15, in
f.flush()
File "/usr/lib/python2.7/dist-packages/nxs/napi.py", line 397, in flush
raise NeXusError, "Could not flush NeXus file %s"%(self.filename)
nxs.napi.NeXusError:
It seems that the fix is not enought
this test failed at the flush
import nxs
f = nxs.open("/tmp/foo.h5", "w5")
f.makegroup('entry', 'NXentry')
f.opengroup('entry')
f.makegroup('g', 'NXcollection')
f.opengroup('g', 'NXcollection')
f.makedata('d', 'float64', shape=(1,))
f.opendata('d')
f.putdata(1
Here after rebuilding hdf5 in debug mode
:~/Debian/nexus$ ./bug.py
H5get_libversion(majnum=0xbf8a5b04, minnum=0xbf8a5b08, relnum=0xbf8a5b0c) =
SUCCEED;
H5Eset_auto2(estack=H5P_DEFAULT, func=NULL, client_data=NULL) = SUCCEED;
H5open() = SUCCEED;
H5Pcreate(cls=8 (genprop class)) = 18 (genprop list)
activating the NXError reporting we got
filenamenxs.h5 5
ERROR: cannot open file: filenamenxs.h5
0
and looking for this errormessage,
we found it in the napi5.c file
NXstatus NX5open(CONSTCHAR *filename, NXaccess am,
NXhandle* pHandle)
{
hid_t attr1,ai
Herethe code ofthismethod
/**/
static NXstatus NXinternalopen(CONSTCHAR *userfilename, NXaccess am,
pFileStack fileStack);
/*--*/
NXstatus NXopen(
in the napi.h files we saw this.
define CONCAT(__a,__b) __a##__b/* token concatenation */
#ifdef __VMS
#define MANGLE(__arg) __arg
#else
#define MANGLE(__arg) CONCAT(__arg,_)
#endif
#define NXopen MANGLE(nxiopen)
/**
* Open a NeXus fi
Let's instrument the code
print filename, mode, _ref(self.handle)
status = nxlib.nxiopen_(filename,mode,_ref(self.handle))
print status
$ python bug.py
filenamenxs.h5 5
0
Hello
here the napi code which cause some trouble.
# Convert open mode from string to integer and check it is valid
if mode in _nxopen_mode: mode = _nxopen_mode[mode]
if mode not in _nxopen_mode.values():
raise ValueError, "Invalid open mode %s",str(mode)
> Ehm, yes. :)
so I just tested an upgrade from jessie to sid of tango-db and it works :)))
Now I have only one concern about the dump.
Since we had a failure with the dump when it ran as user, we discovered that
our procedures where wrong and necessitate the dbadmin grants in order to works.
W
Hello Paul
> Officially, no, because the documentation says: "If files exist in both
> data and scripts, they will both be executed in an unspecified order."
> However, the current behavior of dbconfig-common is to first run the
> script and then run the admin code and then run the user code. So y
Hello Paul
> I really hope I can upload this weekend. I have code that I believe does
> what I want. I am in the process of testing it.
thanks a lot.
> [...]
> What I meant,
> instead of the mysql code that runs as user, run a script for the
> upgrade (they are run with database administrator
Hello Paul,
> Once I fixed 850190,
Do you think that you will fix this bug before next week in order to let me
enought time to fix tango and upload it.
> I believe that ought to work, although that is
> still a hack. I was thinking of doing the "DROP PROCEDURE IF EXISTS *"
> calls with the adm
Hello,
I discuss with the tango-db upstream and he found that
this one line fixed the problem, befrore doing the tango-db upgrade
UPDATE mysql.proc SET Definer='tango@localhost' where Db='tango';
Ideally it should be something like
UPDATE mysql.proc SET Definer='xxx' where Db='yyy';
where xxx
Hello,
> I am suspecting that this commit may be related to the current behavior:
> https://anonscm.debian.org/cgit/collab-maint/dbconfig-common.git/commit/?id=acdb99d61abfff54630c4cfba6e4452357a83fb9
> I believe I implemented there that the drop of the database is performed
> with the user privi
1 - 100 of 167 matches
Mail list logo
