The bug still exists in current Squeeze. I agree with Patrick: This bug
will bite many people when Squeeze is released.
If the patches in #22 are too difficult to backport, I propose to simply
use the workaround available at
https://dev.openwrt.org/ticket/6192#comment:4
- for me that
Might be related that box running a grsec kernel.
Seems so:
http://bugs.python.org/issue5504
http://bugs.gentoo.org/show_bug.cgi?id=329499
http://bugs.gentoo.org/attachment.cgi?id=240887action=diff
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of
Package: python2.6
Version: 2.6.6-3
Severity: normal
*** Please type your report below this line ***
import ctypes results in a segfault:
# python
Python 2.6.6 (r266:84292, Aug 29 2010, 19:11:12)
[GCC 4.4.5 20100824 (prerelease)] on linux2
Type help, copyright, credits or license for more
import ctypes
Segmentation fault
unable to reproduce.
...
we would have more bug reports if _ctypes would be broken. so please
investigate why it fails for you.
Any pointers how to do that?
Looking at the openwrt bug report, I guess that's some compiler problem or
something. Might be
Attached you find an (untested) patch for bug 580039. xdb_file didn't
distinguish errors reading a file and files not existing. I think that
patch should fix this but I'm not sure the new error mode (return r_ERR)
is handled properly in calling functions.
While the namespace conversion
On Thu, 20 May 2010, Matthias Wimmer wrote:
Checking if there is still something that I have to do before I can
release it.
It'd be cool if you could comment on the crashing issues (see the
backtraces I sent to you). I added changeset 1534 locally but that didn't
help, and I see no obvious
It might be worthwhile to update to the
http://svn.jabberd.org/branches/RELEASE-1_6_1
branch. There seem to be some fixes in there.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Package: jabberd14
Version: 1.6.1.1-5
Severity: normal
On a medium-sized server (max 150 concurrent connections, about 500 active
accounts), jabberd segfaults frequently (about four times per day).
jabberd 1.4.4 didn't exhibit this behaviour.
There seem to be multiple places where crashes
I'm not sure Matthias supports xdb_file and jadc2s since AFAIK he does not
use these components and his time is limited these days. I filed these
bugs mostly for reference.
I guess this is more or less the minimal account xml triggering bug 580039
in the Konverse case (I don't know where the
Package: jabberd14
Version: 1.6.1.1-5
Severity: normal
It seems that jabberd14 1.6 is more restrictive on namespace handling in
its xdb files than jabberd 1.4 but fails to convert old files correctly -
if it does any conversion, that is. This seems to break most accounts of
people who have
Package: jabberd14
Version: 1.6.1.1-5
Severity: normal
Legacy SSL connections using the pthsock tls/ configuration option seem to
break if more than a handful of connections have been established.
openssl s_client -connect jabberhost:5223 hangs after CONNECTED(0003)
then. STARTTLS
Package: jabberd14
Version: 1.6.1.1-5
Severity: normal
jabberd14 fails to open any sockets if a kernel without IPv6 support
is running. This should be documented or checked on installation.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe.
Package: bittornado
Version: 0.3.18-8
Severity: normal
When launching bittorrent (btdownloadmany(curses) in my case), it often
ceases to do anything after a while, without any error message. It just
doesn't update its output or download anymore.
I added some debug code; it seems that it does
Seems there is an undocumented max_files_open option (50 by default).
Like several other options this seems to apply per-torrent only though,
making this option somewhat useless with btlaunchmany*.
So this is basically three bugs:
1) Some exceptions (e.g., in storage.py) make bt crash/hang
2)
Package: xmms-kde
Version: 3.2-2+b1
Severity: important
On the dual-core AMD CPU I upgraded to recently, kicker hangs from time to
time. This seems to be related to xmms-kde: If xmms is not running, the
hangs do not occur. If I kill xmms when kicker hangs, kicker resumes
working. Seems
Package: installation-reports
Debian-installer-version:
http://cdimage.debian.org/pub/cdimage-testing/daily/amd64/20050929/debian-testing-amd64-netinst.iso
and
http://cdimage.debian.org/pub/cdimage-testing/daily/amd64/20051002/debian-testing-amd64-businesscard.iso
uname -a: No idea
Date:
16 matches
Mail list logo