Bug#1027894: Bug confirm
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 (gdb) bt #0 0x714efb03 in QMediaDevices::audioOutputs() () at /lib/x86_64-linux-gnu/libQt6Multimedia.so.6 #1 0x714f1825 in QMediaDevices::defaultAudioOutput() () at /lib/x86_64-linux-gnu/libQt6Multimedia.so.6 #2 0x714d4a89 in QAudioOutput::QAudioOutput(QObject*) () at /lib/x86_64-linux-gnu/libQt6Multimedia.so.6 #3 0x715a55f9 in () at /usr/lib/python3/dist-packages/PyQt6/QtMultimedia.abi3.so #4 0x715a5742 in () at /usr/lib/python3/dist-packages/PyQt6/QtMultimedia.abi3.so #5 0x753912fc in () at /usr/lib/python3/dist-packages/PyQt6/sip.cpython-310-x86_64-linux-gnu.so #6 0x556cfd7a in _PyObject_MakeTpCall () #7 0x556ca092 in _PyEval_EvalFrameDefault () #8 0x556cf014 in _PyObject_FastCallDictTstate () #9 0x556e227c in () #10 0x556cfd7a in _PyObject_MakeTpCall () #11 0x556ca092 in _PyEval_EvalFrameDefault () #12 0x5579fa90 in () #13 0x5579f9e2 in PyEval_EvalCode () #14 0x557a4d67 in () #15 0x556d9224 in () #16 0x556cac5b in _PyEval_EvalFrameDefault () #17 0x556d8fd5 in _PyFunction_Vectorcall () #18 0x556c9d02 in _PyEval_EvalFrameDefault () #19 0x556d8fd5 in _PyFunction_Vectorcall () #20 0x556c534d in _PyEval_EvalFrameDefault () #21 0x556d8fd5 in _PyFunction_Vectorcall () #22 0x556c5163 in _PyEval_EvalFrameDefault () #23 0x556d8fd5 in _PyFunction_Vectorcall () #24 0x556c5163 in _PyEval_EvalFrameDefault () #25 0x556d8fd5 in _PyFunction_Vectorcall () #26 0x556d8447 in () #27 0x557a479c in _PyObject_CallMethodIdObjArgs () #28 0x555ddcc6 in () #29 0x556c7b2c in _PyEval_EvalFrameDefault () #30 0x5579fa90 in () #31 0x5579f9e2 in PyEval_EvalCode () #32 0x557c5d53 in () #33 0x557c058a in () #34 0x557c5ae2 in () #35 0x557c517a in _PyRun_SimpleFileObject () #36 0x557c4ed4 in _PyRun_AnyFileObject () #37 0x557b8c0c in Py_RunMain () #38 0x55794e67 in Py_BytesMain () #39 0x77cbc18a in __libc_start_call_main (main=main@entry=0x55794e30, argc=argc@entry=2, argv=argv@entry=0x7fffe7c8) at ../sysdeps/nptl/libc_start_call_main.h:58 #40 0x77cbc245 in __libc_start_main_impl (main=0x55794e30, argc=2, argv=0x7fffe7c8, init=, fini=, rtld_fini=, stack_end=0x7fffe7b8) at ../csu/libc-start.c:381 #41 0x55794d61 in _start () It seems something internal to Qt6Multimedia or PyQt, I wonder if one of those packages don't need to be recompiled after some ABI change. But it could be something else, I'm no expert in Qt. Regards, -- Gaël Le Mignot - g...@pilotsystems.net Pilot Systems - 82, rue de Pixérécourt - 75020 Paris Tel : +33 1 44 53 05 55 - www.pilot-systems.net Découvrez notre offre Cloud privé 100% infogéré - www.pilotsystems.net/cloud/
Bug#962322: Workaround for this bug
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 def build_Constant(self, o): return o.value _Builder3.build_Constant = build_Constant It's not very elegant, but it should allow people to upgrade to bullseye until the package is fixed (which might not be trivial). Regards,
Bug#993575: heartbeat: Heartbeat not starting due to missing directory after bullseye upgrade
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 heartbeat.service" and adding : [Service] RuntimeDirectory=heartbeat RuntimeDirectoryMode=755 fixes the issue. But shouldn't a standard buster => bullseye upgrade work smoothly without having to do such kind of workaround ? I didn't try a fresh install of heartbeat on bullseye yet, not sure what's the behavior then. Regards, -- System Information: Debian Release: 11.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/1 CPU thread) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages heartbeat depends on: ii adduser 3.118 ii cluster-glue 1.0.12-20 ii gawk 1:5.1.0-1 ii iproute2 5.10.0-4 ii iputils-ping [ping] 3:20210202-1 ii libc62.31-13 ii libglib2.0-0 2.66.8-1 ii libheartbeat21:3.0.6-11 ii libpam-runtime 1.4.0-9 ii libpils2 1.0.12-20 ii libplumb21.0.12-20 ii libplumbgpl2 1.0.12-20 ii libstonith1 1.0.12-20 ii libxml2-utils2.9.10+dfsg-6.7 ii psmisc 23.4-2 ii python3 3.9.2-3 ii resource-agents 1:4.7.0-1 Versions of packages heartbeat recommends: ii iptables 1.8.7-1 ii logrotate3.18.0-2 pn pacemaker ii rsyslog [system-log-daemon] 8.2102.0-2 heartbeat suggests no packages. -- no debconf information
Bug#960266: php-net-sieve: Warnings due to case-insensitive constants and php 7.3
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 : ~ $ echo '' | php -d error_reporting=E_ALL PHP Deprecated: define(): Declaration of case-insensitive constants is deprecated in /usr/share/php/Net/Sieve.php on line 53 PHP Deprecated: define(): Declaration of case-insensitive constants is deprecated in /usr/share/php/Net/Sieve.php on line 60 PHP Deprecated: define(): Declaration of case-insensitive constants is deprecated in /usr/share/php/Net/Sieve.php on line 67 There seems to be an upstream version (1.4.4) which fixes that problem, could the package be updated ? Regards, -- System Information: Debian Release: 10.1 APT prefers stable APT policy: (700, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-6-amd64 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages php-net-sieve depends on: ii php-common 2:69 ii php-net-socket 1.0.14-2 Versions of packages php-net-sieve recommends: ii php-auth-sasl 1.0.6-3 php-net-sieve suggests no packages. -- no debconf information
Bug#842251: linux-image-3.16.0-4-amd64: tx hang, server reboot with driver igb under load
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 very disrupting when they happen on production servers. The setup Hardware : - SuperMicro servers - Dual AMD Opteron - Network card integrated in motherboard : Intel Corporation 82576 Gigabit Network Connection Software stack is : - Xen hypervisor (4.4.1) - Debian GNU/Linux stable - Jessie (8.x) - Linux 3.16.0-4 (Debian’s package) Integrated igb driver (5.0.5-k) In addition we use the following technologies : - DRBD for disk replication ; - taged vlans ; - ethernet bridges. Those servers being currently used in production, additional testing might be complicated. Symptoms Occasionally, the following events occur : - timeout on DRBD : [22020289.869016] block drbd7: Remote failed to finish a request within ko-count * timeout - followed by a tx hang: [22020294.529389] igb :02:00.0: Detected Tx Unit Hang - followed by an attempt to reset network adapter : [22020301.536766] igb :02:00.0 eth0: Reset adapter [22020304.674250] igb :02:00.0 eth0: igb: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX - but the problem persists : [22020306.530956] igb :02:00.0: Detected Tx Unit Hang - after a couple of similar cycles, the server reboots. What we tried We tried the following operations, which didn’t solve the problem : - upgrading the kernel to 4.1.0-0.bpo.2 (igp version 5.2.15-k) ; - replacing the embedded network card by an external one (which uses the same driver) : Intel Corporation I350 Gigabit Network Connection We tried to temporarily remove one of the servers from the datacenter to perform stress testing, but we couldn’t reproduce the crash outside real-world operations. Additional informations Other similar, but slightly older, servers don’t seem to exhibit the same issue. We uploaded additional information to http://www-in.pilotsystems.net/igp/ : - the full logs of last crash/reboot ; - lspci -v, ethtool -i, ethtool -k, dmidecode on a server with the issue (gandalf) and another one that seems fine (buffy) -- Package-specific info: ** Version: Linux version 3.16.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) ** Command line: placeholder root=UUID=6bf5de99-e5c2-4d9a-9be1-b61dd5cafaa6 ro maxcpus=2 ** Not tainted ** Kernel log: [ 105.507922] xenbr1: port 8(vif16.0) entered forwarding state [ 105.817125] device vif18.0 entered promiscuous mode [ 105.819729] IPv6: ADDRCONF(NETDEV_UP): vif18.0: link is not ready [ 108.407058] vif vif-18-0 vif18.0: Guest Rx ready [ 108.407166] IPv6: ADDRCONF(NETDEV_CHANGE): vif18.0: link becomes ready [ 108.407308] xenbr1: port 10(vif18.0) entered forwarding state [ 108.407410] xenbr1: port 10(vif18.0) entered forwarding state [ 108.410195] xen-blkback:ring-ref 770, event-channel 14, protocol 1 (x86_64-abi) [ 108.444016] xen-blkback:ring-ref 771, event-channel 15, protocol 1 (x86_64-abi) [ 108.786623] drbd afdas-gpp: PingAck did not arrive in time. [ 108.786741] drbd afdas-gpp: peer( Secondary -> Unknown ) conn( SyncSource -> NetworkFailure ) [ 109.015336] drbd afdas-gpp: asender terminated [ 109.015436] drbd afdas-gpp: Terminating drbd_a_afdas-gp [ 109.124500] block drbd7: net_ee not empty, killed 4 entries [ 109.124603] drbd afdas-gpp: Connection closed [ 109.124733] drbd afdas-gpp: conn( NetworkFailure -> Unconnected ) [ 109.124857] drbd afdas-gpp: receiver terminated [ 109.124965] drbd afdas-gpp: Restarting receiver thread [ 109.125062] drbd afdas-gpp: receiver (re)started [ 109.125163] drbd afdas-gpp: conn( Unconnected -> WFConnection ) [ 109.774633] drbd afdas-plone5: PingAck did not arrive in time. [ 109.774753] drbd afdas-plone5: peer( Secondary -> Unknown ) conn( SyncSource -> NetworkFailure ) [ 109.831693] drbd afdas-plone5: asender terminated [ 109.831791] drbd afdas-plone5: Terminating drbd_a_afdas-pl [ 112.238925] block drbd8: net_ee not empty, killed 4 entries [ 112.239027] drbd afdas-plone5: Connection closed [ 112.239130] drbd afdas-plone5: conn( NetworkFailure -> Unconnected ) [ 112.239231] drbd afdas-plone5: receiver terminated [ 112.239326] drbd afdas-plone5: Restarting receiver thread [ 112.239417] drbd afdas-plone5: receiver (re)started [ 112.239514] drbd afdas-plone5: conn( Unconnected -> WFConnection ) [ 116.855936] drbd afdas-gpp: initial packet S crossed [ 117.565280] drbd afdas-gpp: Handshake successful: Agreed network protocol version 101 [ 117.565442] drbd afdas-gpp: Agreed to support TRIM on protocol level [ 117.565672] drbd afdas-gpp: conn( WFConnection -> WFReportParams ) [ 117.565807] drbd afdas-gpp: Starting asender thread (from drbd_r_afdas-gp [1785]) [
Bug#814855: Will it be fixed later ?
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. And using an older kernel is not really an option, I plan to buy a graphic card requiring AMDGPU driver soon, so there will no option to have both my GPU and my soundcard working on Debian ? I don't really know the details about NVDIMM_PFN and what it implies, but this current situation seems problematic and I hope a solution can be found. Regards,
Bug#748208: python-django: Upstream security fix not in Debian package ?
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 archive. Is the Debian version unaffeted ? Or else, could you make a new release including the latest security fixes ? Thanks for your work on packaging Django to Debian. Regards, -- System Information: Debian Release: 7.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=fr_FR.utf-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages python-django depends on: ii python 2.7.3-4 Versions of packages python-django recommends: ii libjs-jquery 1.7.2+dfsg-1 Versions of packages python-django suggests: pn geoip-database-contrib none pn gettext none pn python-flup none pn python-mysqldb none pn python-psycopg none ii python-psycopg2 2.4.5-1 pn python-sqlite none ii python-yaml 3.10-4 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710522: Problem found
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 freeze with Xen, try various clocksource options. Regards, -- Gaël Le Mignot - g...@pilotsystems.net Pilot Systems - 82, rue de Pixérécourt - 75020 Paris Tel : +33 1 44 53 05 55 - www.pilot-systems.net Gérez vos contacts et vos newsletters : www.cockpit-mailing.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717500: mesa: Please add support for OpenCL/GalliumCompute
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 of Mesa. Regards, -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.10-1-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR@euro (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#715033: gunicorn: Add a conf-enabled/conf-available like on Apache
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 that official Debian packages will be shipping with gunicorn worker configurations, the ability to have configs available but not enabled does not seem particularly useful. Yes, of course, it wasn't for the default configurations; it's more like with Apache, on our production or pre-production servers, we sometimes have to temporarily disable a site. We can do it by moving the file to another place than /etc/gunicorn.d but having the same kind of system than Apache (between /etc/apache2/sites-available and /etc/apache2/sites-enabled) would be convenient. It can also be used to have centralised available configuration when deploying on a cluster, even the enabled configurations aren't the same of each node (like, some configurations are only enabled in case of failure on one node). More generally, we use gunicorn with Apache, and having the enable/available in one and not with the other is a bit frustrating, but it is indeed a very low-priority request. Regards, -- Gaël Le Mignot - g...@pilotsystems.net Pilot Systems - 82, rue de Pixérécourt - 75020 Paris Tel : +33 1 44 53 05 55 - www.pilot-systems.net Gérez vos contacts et vos newsletters : www.cockpit-mailing.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#715032: gunicorn: Ignore ~ files in /etc/gunicorn.d
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 automatic backups ending with ~ that some text editors generate. Just adding ~$ to the regexp would do, like : re_ignore = re.compile(r'(~$|^_|\.(dpkg-(old|dist|new|tmp)|example)$|\.pyc|\.comc$)') Regards, -- System Information: Debian Release: 7.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=fr_FR@euro (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/dash Versions of packages gunicorn depends on: ii python2.7.3-4 ii python-pkg-resources 0.6.24-1 ii python-setuptools 0.6.24-1 gunicorn recommends no packages. Versions of packages gunicorn suggests: pn python-geventnone pn python-pastedeploy none pn python-setproctitle none pn python-tornado none -- Configuration Files: /etc/init.d/gunicorn changed [not included] -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#715033: gunicorn: Add a conf-enabled/conf-available like on Apache
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 /etc/gunicorn/conf-enabled , with files in it being symlinks to real ones in /etc/gunicorn/conf-available . The default example files should then be in /etc/gunicorn/conf-available . Regards, -- System Information: Debian Release: 7.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=fr_FR@euro (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/dash Versions of packages gunicorn depends on: ii python2.7.3-4 ii python-pkg-resources 0.6.24-1 ii python-setuptools 0.6.24-1 gunicorn recommends no packages. Versions of packages gunicorn suggests: pn python-geventnone pn python-pastedeploy none pn python-setproctitle none pn python-tornado none -- Configuration Files: /etc/init.d/gunicorn changed [not included] -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697585: lvm2: pvmove freezes the whole vg with running Xen VMs
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 Event number: 0 Major, minor: 253, 15 Number of targets: 1 UUID: LVM-Swainyf93G2725pwjrc6e6IPwiQKKW1CyVNJQCOfaCdyshVvqOXV7YqCJ5GM3nPC Name: iroquois-uns--swap--new State: ACTIVE Read Ahead:256 Tables present:LIVE Open count:1 Event number: 0 Major, minor: 253, 31 Number of targets: 1 UUID: LVM-Swainyf93G2725pwjrc6e6IPwiQKKW1C6IUer7zAckX3bTIh2eU9OgVHabxjVBcZ Name: iroquois-cockpitng--sql State: ACTIVE Read Ahead:256 Tables present:LIVE Open count:1 Event number: 0 Major, minor: 253, 17 Number of targets: 1 UUID: LVM-Swainyf93G2725pwjrc6e6IPwiQKKW1CmBEmWIY9SBoUcilkvx1WkFWjHL0cVNhv Name: iroquois-uns--disk--new State: ACTIVE Read Ahead:256 Tables present:LIVE Open count:1 Event number: 0 Major, minor: 253, 30 Number of targets: 1 UUID: LVM-Swainyf93G2725pwjrc6e6IPwiQKKW1Cva2e427Id3eDh36HlwekSBKA6SKOrEf3 Name: iroquois-uns--swap State: ACTIVE Read Ahead:256 Tables present:LIVE Open count:0 Event number: 0 Major, minor: 253, 13 Number of targets: 1 UUID: LVM-Swainyf93G2725pwjrc6e6IPwiQKKW1CNOtSXbEFb6B3T5f5C8cYpxb0Kt1GCmx2 Name: iroquois-pvmove0 State: ACTIVE Read Ahead:256 Tables present:LIVE Open count:4 Event number: 1 Major, minor: 253, 12 Number of targets: 4 UUID: LVM-Swainyf93G2725pwjrc6e6IPwiQKKW1CK2KOGx9JNGLqcrvNt83Rmii2rNeRcdl2 Name: iroquois-fr--pilo1--svr01--disk State: ACTIVE Read Ahead:256 Tables present:LIVE Open count:1 Event number: 0 Major, minor: 253, 16 Number of targets: 1 UUID: LVM-Swainyf93G2725pwjrc6e6IPwiQKKW1Cur52grQPtfg12t9qu3mxJH8oqgeGRJE8 And dmsetup table: iroquois-fr--pilo1--svr01--swap: 0 262144 linear 253:12 42205184 iroquois-uns--swap--new: 0 262144 linear 9:3 115868032 iroquois-cockpitng--sql: 0 62914560 linear 9:3 125829504 iroquois-uns--disk--new: 0 62914560 linear 9:3 188744064 iroquois-uns--swap: 0 262144 linear 253:12 0 iroquois-pvmove0: 0 262144 linear 9:3 384 iroquois-pvmove0: 262144 41943040 mirror core 1 1024 2 9:4 463208832 9:3 52953472 iroquois-pvmove0: 42205184 262144 linear 9:4 549192064 iroquois-pvmove0: 42467328 20971520 linear 9:4 549454208 iroquois-fr--pilo1--svr01--disk: 0 20971520 linear 253:12 42467328 Also please test with the current versions in Wheezy. The problem occured on a production server, I'm sorry, but I can't upgrade it to testing, nor take any risk of recreating the problem (which requires a reboot of the whole server and all its virtual machines). Regards, -- Gaël Le Mignot - g...@pilotsystems.net Pilot Systems - 82, rue de Pixérécourt - 75020 Paris Tel : +33 1 44 53 05 55 - www.pilotsystems.net Gérez vos contacts et vos newsletters : www.cockpit-mailing.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697585: lvm2: pvmove freezes the whole vg with running Xen VMs
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 PV within a VG, while the virtual machines where running. pvmove froze at around 66% of completion, and afterwards, all access to the VG, both from the virtual machines and the DOM0 froze. Any lvm command (pvs, lvs, ...) would freeze too, and enter unkillable D state. Here is a traceback we had on a frozen pvs : Jan 4 12:12:24 buffy kernel: [584522.464110] INFO: task pvs:23197 blocked for more than 120 seconds. Jan 4 12:12:24 buffy kernel: [584522.468010] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. Jan 4 12:12:24 buffy kernel: [584522.468010] pvs D 88007dd5e350 0 23197 23196 0x Jan 4 12:12:24 buffy kernel: [584522.468010] 88007d62a350 0286 88007e230200 88007cc3e2b0 Jan 4 12:12:24 buffy kernel: [584522.468010] 88007ef0c208 01d88023 f9e0 88007ec53fd8 Jan 4 12:12:24 buffy kernel: [584522.468010] 00015780 00015780 88007dd5e350 88007dd5e648 Jan 4 12:12:24 buffy kernel: [584522.468010] Call Trace: Jan 4 12:12:24 buffy kernel: [584522.468010] [8106cbaa] ? timekeeping_get_ns+0xe/0x2e Jan 4 12:12:24 buffy kernel: [584522.468010] [8130ce0a] ? io_schedule+0x73/0xb7 Jan 4 12:12:24 buffy kernel: [584522.468010] [811154a9] ? __blockdev_direct_IO+0x910/0xa60 Jan 4 12:12:24 buffy kernel: [584522.468010] [81113966] ? blkdev_direct_IO+0x45/0x4a Jan 4 12:12:24 buffy kernel: [584522.468010] [81112c7b] ? blkdev_get_blocks+0x0/0x8b Jan 4 12:12:24 buffy kernel: [584522.468010] [810b680b] ? generic_file_aio_read+0xf6/0x536 Jan 4 12:12:24 buffy kernel: [584522.468010] [a01abb05] ? dm_blk_open+0x10/0x5f [dm_mod] Jan 4 12:12:24 buffy kernel: [584522.468010] [81114021] ? __blkdev_get+0x29c/0x342 Jan 4 12:12:24 buffy kernel: [584522.468010] [811140ce] ? blkdev_open+0x0/0x96 Jan 4 12:12:24 buffy kernel: [584522.468010] [81114135] ? blkdev_open+0x67/0x96 Jan 4 12:12:24 buffy kernel: [584522.468010] [810f0101] ? do_sync_read+0xce/0x113 Jan 4 12:12:24 buffy kernel: [584522.468010] [810f3453] ? cp_new_stat+0xe9/0xfc Jan 4 12:12:24 buffy kernel: [584522.468010] [81066092] ? autoremove_wake_function+0x0/0x2e Jan 4 12:12:24 buffy kernel: [584522.468010] [81112f16] ? block_ioctl+0x38/0x3c Jan 4 12:12:24 buffy kernel: [584522.468010] [810fbf62] ? vfs_ioctl+0x21/0x6c Jan 4 12:12:24 buffy kernel: [584522.468010] [810fc4b0] ? do_vfs_ioctl+0x48d/0x4cb Jan 4 12:12:24 buffy kernel: [584522.468010] [810f0b24] ? vfs_read+0xa6/0xff Jan 4 12:12:24 buffy kernel: [584522.468010] [810f0c39] ? sys_read+0x45/0x6e Jan 4 12:12:24 buffy kernel: [584522.468010] [81011b42] ? system_call_fastpath+0x16/0x1b The virtual machines on other VG were still functionnal, only those using the VG running pvmove were frozen (those using the source and the target PV were both affected). pvmove --abort froze too. We had to do a physical reset on the whole server to recover from the situation. No data was lost, but it created some significant downtime to our services. The version of Xen we use is 4.0.1-5.5 -- System Information: Debian Release: 6.0.6 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-xen-amd64 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=fr_FR@euro (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/dash Versions of packages lvm2 depends on: ii dmsetup 2:1.02.48-5 The Linux Kernel Device Mapper use ii libc6 2.11.3-4 Embedded GNU C Library: Shared lib ii libdevmapper1.02.1 2:1.02.48-5 The Linux Kernel Device Mapper use ii libreadline55.2-7GNU readline and history libraries ii libudev0164-3libudev shared library ii lsb-base3.2-23.2squeeze1 Linux Standard Base 3.2 init scrip lvm2 recommends no packages. lvm2 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#660086: Some additional information
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 this cleanly without any side-effect, it seems quite deep into the ZPublisher. -- Gaël Le Mignot - g...@pilotsystems.net Pilot Systems - 9, rue Desargues - 75011 Paris Tel : +33 1 44 53 05 55 - www.pilotsystems.net Gérez vos contacts et vos newsletters : www.cockpit-mailing.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653802: Fwd: removal of python2.6 (and removal of zope2.12 for wheezy)
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 sad to end up not being able to. More generally, I would really like to have the default Python version of release N to be available on release N+1. Python 2.6 is the default Python version on Squeeze, so we have like 100 of servers using Python 2.6 to run various applications. Since Python 2.7 is not available in Squeeze, we can't migrate/test those applications to Python 2.7 in Squeeze, and if Python 2.6 isn't in Wheezy, we won't be able to migrate the OS to Wheezy and then the apps to Python 2.7, which makes the transition quite painful. I'm not sure how common this is, but I'll guess than all hosting providers who use massively Python are in a similar situation than we are, and would really like to have Python 2.6 in Wheezy to smooth the transition (and more generally, the default version of Python in Debian release N to still be available in release N-1). Regards, -- Gaël Le Mignot - g...@pilotsystems.net Pilot Systems - 9, rue Desargues - 75011 Paris Tel : +33 1 44 53 05 55 - www.pilotsystems.net Gérez vos contacts et vos newsletters : www.cockpit-mailing.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653802: please remove explicit python2.6 (build)-dependencies
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 2.13 in the future, but upgrading complex web sites from a version of Plone to another is often very painful (incompatible add-on products, complicated migration of the content, ...). As a matter of facts, at Pilot Systems (the Free Software service provider I work at) we were forced to forward-port Python 2.4 from lenny to squeeze, because we have too many Plone 3/Zope 2.10/Python 2.4 websites to be able to migrate them all to Plone 4 in time for the Lenny end of life. If it really is too complicated to keep Python 2.6 around in wheezy for the package mainteners or the security team, I can understand it, but it would be very painful for us to not have Python 2.6 in wheezy. Python 2.6 is the default Python version in squeeze. Would it be possible, as a general policy and to ease migrations, to always have the default Python version of n-1 available in n ? The default version of squeeze available in wheezy, the default version of wheezy available in the next one, ... ? It would really help a lot for migrations of complex architectures. Regards, -- Gaël Le Mignot - g...@pilotsystems.net Pilot Systems - 9, rue Desargues - 75011 Paris Tel : +33 1 44 53 05 55 - www.pilotsystems.net Gérez vos contacts et vos newsletters : www.cockpit-mailing.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
