Bug#939571: uploaded a NMU, delayed 15 days
Same here: my build of the taurus-pyqtgraph package is now working again in sid. Thanks!
Bug#939571: Fails to import
Just adding that I checked and 0.10.0-1 is not affected. Note this bug is affecting the to build the taurus-pyqtgraph package: https://salsa.debian.org/science-team/taurus-pyqtgraph/-/jobs/362247
Bug#940822: silx view crashes on invocation
Thanks for the investigation! I can only add that the version of python3-qt5 available for stretch (5.7+dfsg-5) was not affected by this.
Bug#940822: silx view crashes on invocation
On Friday, September 20, 2019 11:21:29 AM CEST PICCA Frederic-Emmanuel wrote: > gdb -ex r --args python3 -m silx.app.view.main Please find attached the output -- ++ Carlos Pascual Izarra Scientific Software Coordinator Computing Division ALBA Synchrotron [http://www.albasynchrotron.es] Carrer de la Llum 2-26 E-08290 Cerdanyola del Valles (Barcelona), Spain E-mail: cpasc...@cells.es Phone: +34 93 592 4428 ++:~$ gdb -ex r --args python3 -m silx.app.view.main GNU gdb (Debian 8.2.1-2+b1) 8.2.1 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from python3...(no debugging symbols found)...done. Starting program: /usr/bin/python3 -m silx.app.view.main [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Detaching after fork from child process 10654] [New Thread 0x7fffee6ba700 (LWP 10656)] malloc_consolidate(): invalid chunk size Thread 1 "python3" received signal SIGABRT, Aborted. __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x779b3535 in __GI_abort () at abort.c:79 #2 0x77a0a508 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x77b1528d "%s\n") at ../sysdeps/posix/libc_fatal.c:181 #3 0x77a10c1a in malloc_printerr (str=str@entry=0x77b16b68 "malloc_consolidate(): invalid chunk size") at malloc.c:5341 #4 0x77a10f2a in malloc_consolidate (av=av@entry=0x77b4cc40 ) at malloc.c:4471 #5 0x77a13a58 in _int_malloc (av=av@entry=0x77b4cc40 , bytes=bytes@entry=16409) at malloc.c:3695 #6 0x77a1556a in __GI___libc_malloc (bytes=16409) at malloc.c:3057 #7 0x76bcc552 in QArrayData::allocate(unsigned long, unsigned long, unsigned long, QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #8 0x76bce4a0 in QByteArray::QByteArray(int, Qt::Initialization) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #9 0x76c365b8 in QRingBuffer::reserve(long long) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #10 0x76cc09f5 in QIODevicePrivate::read(char*, long long, bool) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #11 0x76cc219a in QIODevice::getChar(char*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #12 0x7fffec0b0242 in ?? () from /usr/lib/x86_64-linux-gnu/libKF5Crash.so.5 #13 0x7fffec0afcd7 in KCrash::initialize() () from /usr/lib/x86_64-linux-gnu/libKF5Crash.so.5 #14 0x76d76e7d in qAddPreRoutine(void (*)()) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #15 0x77fe437a in call_init (l=, argc=argc@entry=3, argv=argv@entry=0x7fffde48, env=env@entry=0xbf19e0) at dl-init.c:72 #16 0x77fe4476 in call_init (env=0xbf19e0, argv=0x7fffde48, argc=3, l=) at dl-init.c:30 #17 _dl_init (main_map=main_map@entry=0xf98aa0, argc=3, argv=0x7fffde48, env=0xbf19e0) at dl-init.c:119 #18 0x77fe82d3 in dl_open_worker (a=a@entry=0x7fffc750) at dl-open.c:517 #19 0x77ac5b2f in __GI__dl_catch_exception (exception=, operate=, args=) at dl-error-skeleton.c:196 #20 0x77fe7bba in _dl_open (file=0xf970d8 "/usr/lib/x86_64-linux-gnu/qt5/plugins/platformthemes/KDEPlasmaPlatformTheme.so", mode=-2147479551, caller_dlopen=0x76d6ffac, nsid=, argc=3, argv=0x7fffde48, env=0xbf19e0) at dl-open.c:599 #21 0x77f38256 in dlopen_doit (a=a@entry=0x7fffc970) at dlopen.c:66 #22 0x77ac5b2f in __GI__dl_catch_exception (exception=exception@entry=0x7fffc910, operate=, args=) at dl-error-skeleton.c:196 #23 0x77ac5bbf in __GI__dl_catch_error (objname=0x8cca90, errstring=0x8cca98, mallocedp=0x8cca88, operate=, args=) at dl-error-skeleton.c:215 #24 0x77f38975 in _dlerror_run (operate=operate@entry=0x77f38200 , args=args@entry=0x7fffc970) at dlerror.c:163 #25 0x77f382e6 in __dlopen (file=, mode=) at dlopen.c:87 #26 0x76d6ff
Bug#940822: silx view crashes on invocation
On Friday, September 20, 2019 10:57:22 AM CEST PICCA Frederic-Emmanuel wrote: > Could it be a problem with the OpenGL drivers on your computer ? It could be something OpenGL-related, but I would not suspect the drivers, since it works well in the same machine when I use the pip version in a virtualnev. I'll try to check some more. > Do you have a backtrace from gdb available ? No. I was not able to produce a core file... The crash is handled by KCrash and even if I set `ulimit -c unlimited` it does not seem to produce a core file. Any hint on how I can produce the backtrace? -- +----+ Carlos Pascual Izarra Scientific Software Coordinator Computing Division ALBA Synchrotron [http://www.albasynchrotron.es] Carrer de la Llum 2-26 E-08290 Cerdanyola del Valles (Barcelona), Spain E-mail: cpasc...@cells.es Phone: +34 93 592 4428 ++
Bug#940822: silx view crashes on invocation
Package: silx Version: 0.9.0+dfsg-3 Severity: important Dear Maintainer, Running `silx view` or `silx test` produces a crash straight away with the following output: ``` ~$ silx view malloc_consolidate(): invalid chunk size KCrash: crashing... crashRecursionCounter = 2 KCrash: Application Name = python3.7 path = /usr/bin pid = 10504 KCrash: Arguments: Alarm clock ``` The expected outcome is a silx view GUI appearing. I also tested with version 0.11.0+dfsg-1~bpo10+1 from buster-backports, with the same result. In contrast, the version 0.11.0 from PyPI (installed in a py3 virtual env with pip) launches fine. -- System Information: Debian Release: 10.1 APT prefers stable APT policy: (900, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages silx depends on: ii python33.7.3-1 ii python3-numpy 1:1.16.2-1 ii python3-silx 0.9.0+dfsg-3 silx recommends no packages. silx suggests no packages. -- no debconf information
Bug#933333: ITP: taurus-pyqtgraph -- Taurus extension providing pyqtgraph-based widgets
Package: wnpp Severity: wishlist Owner: Carlos Pascual * Package name: taurus-pyqtgraph Version : 0.2.4 Upstream Author : Taurus Community * URL : http://github.com/taurus-org/taurus_pyqtgraph * License : LGPL-3+ Programming Lang: Python Description : Taurus extension providing pyqtgraph-based widgets Long description: taurus_pyqtgraph is an extension for the python-taurus package. It adds the taurus.qt.qtgui.tpg submodule which provides pyqtgraph-based widgets. The package is planned to be maintained as part of the Debian Science Team A previous version is already built in Salsa using CI: https://salsa.debian.org/science-team/taurus-pyqtgraph A RFS has already been submitted: https://bugs.debian.org/921548
Bug#921548: taurus-pyqtgraph is building fine in salsa
On Wednesday, March 6, 2019 10:03:55 AM CET PICCA Frederic-Emmanuel wrote: > I do not know how to do this transfer. project settings -> General -> Advanced -> Transfer Project > I am wondering if it is not necessary to open a tick to the salsa > support[1] in order to move a repositor I opened a ticket asking the question: https://salsa.debian.org/salsa/support/issues/140 > to my opinion, all the dependencies should be added during the build, I have not problems doing it if that is the recommended policy,... but I always understood that if a dependency is not needed during build, then it belongs to depends, not build-depends and specially if, like in this case, installing it makes the build a lot more expensive (installing taurus means installing pyqt, pymca, ...) > setuptools, should generate automaticaly the dependencies. In that I agree, but it is a mountain I intend to climb at a later moment ;)
Bug#921548: taurus-pyqtgraph is building fine in salsa
Hi Fred! On Wednesday, March 6, 2019 8:24:27 AM CET PICCA Frederic-Emmanuel wrote: > I can not access the lintian artefacts That's because there are none! ;-) On previous builds [1] I got a few lintian warnings but made the necessary changes to I get rid of them. > > Should taurus-pyqtgraph be transferred from my personal area in salsa to > > debian-science ? > I thing that it would be great :). I tried but I couldn't (probably because of not having enough permissions in science-team group) So I just invited you to be a maintainer of the project so that you can do the transfer > > Should we wait until taurus_4.5.0+dfsg-2 is uploaded? > not necessarely, but maybe you should add a build dependency to > python-taurus >= 4.5.0+dfsg-2, which is the first version with python3 > modules. Are you sure? taurus is **not needed at all** for building taurus-pyqtgraph, and this would add a lot of other dependencies for nothing [1] https://salsa.debian.org/cpascual-guest/taurus-pyqtgraph/-/jobs/136769 -- +------------+ Carlos Pascual Izarra Scientific Software Coordinator Computing Division ALBA Synchrotron [http://www.albasynchrotron.es] Carrer de la Llum 2-26 E-08290 Cerdanyola del Valles (Barcelona), Spain E-mail: cpasc...@cells.es Phone: +34 93 592 4428 ++
Bug#921548: taurus-pyqtgraph is building fine in salsa
Hi, Just an update: the taurus-pyqtgrap package is now building successfully in salsa: https://salsa.debian.org/cpascual-guest/taurus-pyqtgraph It is building two binary packages: python-taurus-pyqtgraph python3-taurus-pyqtgraph All tests are passed except for piuparts which fails due to unavailability of the python3-taurus dependency (provided by taurus_4.5.0+dfsg-2 which is already in salsa, but not yet uploaded) What should I do now? Should taurus-pyqtgraph be transferred from my personal area in salsa to debian-science ? Should we wait until taurus_4.5.0+dfsg-2 is uploaded?
Bug#921548: taurus-pyqtgraph/0.1-1 -- extension for taurus
No. It provides a module called taurus_pyqtgraph which in itself uses taurus-defined entrypoints to plug into different parts of taurus . I've looked at other packages providing plugins, and the current name seems the most appropriate... On February 6, 2019 9:20:54 PM GMT+01:00, PICCA Frederic-Emmanuel wrote: >Hello carlos, > >If your package provide this pyhton module > >taurus.pyqtgraph, > >then the binary package should be named > >python-taurus.pyqtgraph. > > >Cheers > >Frederic
Bug#921548: taurus-pyqtgraph/0.1-1 -- extension for taurus
Package: sponsorship-requests Severity: wishlist Dear mentors, This is my first ITP bug, so please excuse me if I got the procedure wrong somehow. I am looking for a sponsor for a new package that I intend to prepare: "taurus-pyqtgraph", which provides an extension to the existing "taurus" package: * Package name: taurus-pyqtgraph Version : 0.1 Upstream Author : Carlos Pascual * URL : https://github.com/taurus-org/taurus_pyqtgraph * License : LGPL v3+ Section : python It builds those binary packages: python-taurus-pyqtgraph The package has never been uploaded to debian, but we are already building it locally and using it at my institution. And I am currently trying to build it using the debian-salsa CI pipelines: https://salsa.debian.org/cpascual-guest/taurus-pyqtgraph More information about taurus-pyqtgraph can be obtained from https:// github.com/taurus-org/taurus_pyqtgraph Regards, Carlos Pascual
Bug#916195: changed sources in salsa
On Wednesday, December 12, 2018 2:59:53 PM CET PICCA Frederic-Emmanuel wrote: > 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. Fine. I'll remove it. > I understand for the backports. > > do you know if a release is expected before the Debian freeze ? I have no idea, but I don't expect it. > > > Fred -- +--------+ Carlos Pascual Izarra Scientific Software Coordinator Computing Division ALBA Synchrotron [http://www.albasynchrotron.es] Carrer de la Llum 2-26 E-08290 Cerdanyola del Valles (Barcelona), Spain E-mail: cpasc...@cells.es Phone: +34 93 592 4428 ++
Bug#916195: changed sources in salsa
On Wednesday, December 12, 2018 10:23:31 AM CET PICCA Frederic-Emmanuel wrote: > 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 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. So let me know what you prefer. Carlos -- +------------+ Carlos Pascual Izarra Scientific Software Coordinator Computing Division ALBA Synchrotron [http://www.albasynchrotron.es] Carrer de la Llum 2-26 E-08290 Cerdanyola del Valles (Barcelona), Spain E-mail: cpasc...@cells.es Phone: +34 93 592 4428 ++
Bug#916195: changed sources in salsa
Hi Fred, I made the required changes to the package sources in salsa.d.o I hope they are ok. Note that I did not use the -R option to gbp dch, so the fixed version changelog is still marked as UNRELEASED Also, I added my name to the Uploaders. I hope this is ok. If not, feel free to revert my changes. Carlos
Bug#876921: python-pint FTBFS with python-numpy 1.13.1: test failures
Hi, I fixed this in upstream: https://github.com/hgrecco/pint/pull/630
Bug#834393: bug 834393 is now affecting stretch
This is just to confirm that #834393 is now affecting Debian Stable.
Bug#869812: python-pint: Please update to latest upstream version (0.8.1)
Package: python-pint Version: 0.7.2-3 Severity: wishlist Dear Maintainer, Upstream of pint already released 0.8.1 It includes some bug fixes that we (the upstream authors of python-taurus) need for our latest version of Taurus to work. Would you consider updating the python-pint package? Note: we are also packaging python-taurus internally and intend to get involved in the official python-taurus packaging, so we would be happy in helping with the maintainance of python-pint if you need help. Cheers, Carlos -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python-pint depends on: ii dpkg 1.18.24 ii python2.7.13-2 ii python-pkg-resources 33.1.1-1 python-pint recommends no packages. python-pint suggests no packages. -- no debconf information
Bug#861736: Still some regression in python-nxs
Hi,
while nexus 4.3.2-svn1921-5 fixes the originally reported exception, the
fix seems not to be complete [1].
In order to trigger the still-existing regression, run the following
python code (which ideally should exit without errors):
```
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.23)
f.closedata()
f.closegroup()
f.flush()
f.close()
```
In stretch + nexus_4.3.2-svn1921-5, it fails with the following
exception:
```
Traceback (most recent call last):
File "nxs_flush_bug.py", line 12, 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: Could not flush NeXus file /tmp/foo.h5
```
The same code works well when run on a clean jessie (I used an official
debian:stable docker) and it fails with the same exception as above when
run on sid (I used the official debian:unstable docker)
Cheers,
Carlos
[1] I am replying here because this new problem seems likely to be related
with 861736, but if you think that it may be an unrelated bug I'd be glad
to open a new bug
Bug#861900: unblock: python-sardana/2.2.2-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hello, We would like to ask if we could get a pre-approval for unfreezing python-sardana. The pyhon-sardana package depends on python-nxs, which is affected by bug 861736 [1] and thus may drop from stretch. python-sardana is the only rdepends of python-nxs, so we would like to provide a patch for it allowing to substitute the dependency on python-nxs by a dependency on python-h5py [2] Would the unblock be possible? And if so, how much time would we have to provide the new python-sardana patched package? Cheers, Carlos Pascual [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861736 [2] https://github.com/sardana-org/sardana/issues/460 -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#844601: python-spyder: "from spyder.plugins.editor import Editor" hangs the machine
On Sunday, November 27, 2016 6:22:48 PM CET Dmitry Shachnev wrote: > Such code should not be run on module *import* time, it should be run > when the spyder code is first *used*. I completely agree with this. Also, I second the opinion that segfaults when using Qt code without a QApplication is expected behavior. So, IMHO, the bug is in the python-spyder package Cheers, Carlos
Bug#744741: python-pyside: pip/easy_install do not find PySide if it is installed from repos
Package: python-pyside Version: 1.2.1-4 Severity: normal Dear Maintainer, pip and easy_install fail to detect that PySide is already installed from the debian repository If a package depends on PySide, both easy_install and pip try to install PySide regardless of it being already installed. To reproduce: ~~ $ python -c 'import PySide; print PySide.__version__' 1.2.1 $ pip list | grep -i pyside $ ~~ (I expected the pip list command to output PySide info, but got nothing instead) See also: https://github.com/nexpy/nexpy/issues/23 Cheers -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages python-pyside depends on: ii python-pyside.phonon 1.2.1-4 ii python-pyside.qtcore 1.2.1-4 ii python-pyside.qtdeclarative 1.2.1-4 ii python-pyside.qtgui 1.2.1-4 ii python-pyside.qthelp 1.2.1-4 ii python-pyside.qtnetwork 1.2.1-4 ii python-pyside.qtopengl 1.2.1-4 ii python-pyside.qtscript 1.2.1-4 ii python-pyside.qtsql 1.2.1-4 ii python-pyside.qtsvg 1.2.1-4 ii python-pyside.qttest 1.2.1-4 ii python-pyside.qtuitools 1.2.1-4 ii python-pyside.qtwebkit 1.2.1-4 ii python-pyside.qtxml 1.2.1-4 python-pyside recommends no packages. python-pyside suggests no packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743508: perhaps it should be libzmq4?
This makes me wonder if there shouldn't be a libzmq4 package for the 4.x series while leaving the libzmq3 for the 3.x series. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743508: libzmq3: upgrading from 3.2.3 to 4.0.4 breaks python-pytango
Package: libzmq3 Version: 4.0.4+dfsg-2 Severity: normal Dear Maintainer, After upgrading libzmq3 to 4.0.4+dfsg-2, the following stops working: ~$ python import PyTango dev_name = 'sys/database/2' dev = PyTango.DeviceProxy(dev_name) cb = PyTango.utils.EventCallBack() id = dev.subscribe_event(state, PyTango.EventType.CHANGE_EVENT, cb, [], True) (waits forever... till I press CTRL+C) However, if I downgrade to libzmq3 3.2.3, I can repeat the previous python lines and the last one returns immediately without problems as expected. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libzmq3 depends on: ii libc6 2.18-4 ii libgcc11:4.8.2-16 ii libpgm-5.1-0 5.1.118-1~dfsg-0.1 ii libstdc++6 4.8.2-16 ii multiarch-support 2.18-4 libzmq3 recommends no packages. libzmq3 suggests no packages. -- ++ Carlos Pascual Izarra Scientific Software Coordinator Computing Division Cells / Alba Synchrotron [http:/www.cells.es] Carretera BP 1413 de Cerdanyola-Sant Cugat, Km. 3.3 E-08290 Cerdanyola del Valles (Barcelona), Spain E-mail: cpasc...@cells.es Phone: +34 93 592 4428 ++ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
