Hello,
I can confirm the bug on my own Sid, after upgrading end of last week.
A quick GDB gives me the following stacktrace :
Thread 1 "python3" received signal SIGSEGV, Segmentation fault.
0x714efb03 in QMediaDevices::audioOutputs() () from
/lib/x86_64-linux-gnu/libQt6Multimedia.so.6
Hello,
I confirm that the bug seems to still exist in Debian 11 (package
8.9.1-8).
But here is a workaround that seems to work for me (just add that
anywhere in the Python code before loading the configuration) :
# Monkey patch cherrypy config loader
from cherrypy.lib.reprconf import _Builder3
Package: heartbeat
Version: 1:3.0.6-11
Severity: normal
Dear Maintainer,
After upgrading from buster to bullseye on several hosts, "heartbeat"
doesn't start. It tries to create a /run/heartbeat/register socket in
a non-existing /run/heartbeat/ directory.
Doing a "systemctl edit
Package: php-net-sieve
Version: 1.4.1-1
Severity: normal
Dear Maintainer,
When using php-net-sieve on Debian Buster (for example in roundcube,
but it's not specific to it) we have some deprecation warnings due to
PHP 7.3 (the version shipped in Buster).
It can easily be reproduced with PHP CLI
Package: src:linux
Version: 3.16.36-1+deb8u2
Severity: important
Tags: upstream
Dear Maintainer,
Summary of the problem
We have had a few crash under network load on production servers
using the igb network driver. Those crashes are not very
frequent (a couple of times per year at most) but
Hello,
This sounds like a pretty serious bug to me - making a whole serie of
hardware unusuable in Sid.
I have a SB Live! card too, and don't plan to change it anytime soon.
Will that be fixed in a later (like 4.5) kernel version ? I really hope
Stretch won't be released with such a regression.
Package: python-django
Version: 1.4.5-1+deb7u4
Severity: important
Dear Maintainer,
There has been some security fixes by upstream Django, like
https://www.djangoproject.com/weblog/2014/apr/21/security/
which is a few week old, and yet I don't see any DSA nor
patched version in the Debian
Hello,
We found the cause of the bug : we were using clocksource=pit boot
option, when we remove it, the system boots fine.
It's still a bug that the system freezes with that option, but at least
we know have a solution, which makes this bug much less critical.
So if anyone is having
Source: mesa
Version: 9.1.4-1
Severity: wishlist
Dear X Strike Force,
Are there any plan to include support for OpenCL/GalliumCompute in the Debian
build of Mesa ?
There is some support for OpenCL on top of Gallium3D since Mesa 9.0, it would
be nice to have it available in the Debian packages
Hello Chris!
Tue, 9 Jul 2013 14:56:17 +0100, you wrote:
Gael Le Mignot wrote:
It would be nice to have, like for Apache or many other Debian
packages, a available / enabled configuration system for
gunicorn.
Can you think of usecases where this would be useful?
As it is unlikely
Package: gunicorn
Version: 0.14.5-3+deb7u1
Severity: wishlist
Dear Maintainer,
The debian start script of gunicorn automatically loads configuration from
/etc/gunicorn.d .
It already ignores common bogus files: .dpkg-old, .pyc, ...
I think it would be appropriate to also ignore ~ files, the
Package: gunicorn
Version: 0.14.5-3+deb7u1
Severity: wishlist
Dear Maintainer,
It would be nice to have, like for Apache or many other Debian packages, a
available / enabled configuration system for gunicorn. Instead of loading
from /etc/gunicorn.d, the init script could load from
Please show dmsetup info and dmsetup table. I don't know how the Xen
backend drivers react on frozen devices.
dmsetup info (on the concerned vg) :
Name: iroquois-fr--pilo1--svr01--swap
State: ACTIVE
Read Ahead:256
Tables present:LIVE
Open count:1
Package: lvm2
Version: 2.02.66-5
Severity: important
We use Xen and LVM2 with the following configuration : the DOM0 handles several
LVM2 volume groups, and the virtual machines (DOMU) use the logical volumes for
their paravirtualised disks.
We used pvmove to move data from one PV to another
I digged a bit into the code, and it seems ZPublisher isn't using
standard_error_message template to render 404 Not Found errors, but an
hard-coded message from ZPublisher/HTTPResponse.py that is raised by
notFoundError method and then reprocessed later on.
I'm not sure how to fix
Hello,
For Zope itself, there is indeed the issue of Plone. Plone 4 requires
Zope 2.12 and Python 2.6, and being able to run Plone 4 on Debian
servers easily was the main reason for which we (at Pilot Systems)
invested time and energy to have Zope packages, so it would be quite
Hello,
Zope 2.12 depends on Python 2.6, and as said, porting it to Python 2.7
is not a reasonable option.
Zope 2.13 runs on Python 2.7, but many Zope application (like the most
famous Zope application, the CMS Plone) only work with Zope 2.12.
A newer version of Plone will support Zope
17 matches
Mail list logo
