Bug#707983: deluge-gtk: SEGV in libcrypto after few minutes.
Package: deluge-gtk Version: 1.3.3-2+nmu1 Severity: normal I'm seeing this SEGV: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f6af56b9700 (LWP 29927)] 0x7f6b0fc267bd in RC4 () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 My guess it is the same issue as reported here: http://dev.deluge-torrent.org/ticket/2272 -- System Information: Debian Release: 7.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages deluge-gtk depends on: ii deluge-common1.3.3-2+nmu1 ii librsvg2-common 2.36.1-1 ii notification-daemon 0.7.6-1 ii python 2.7.3-4 ii python-glade22.24.0-3+b1 ii python-notify0.1.1-3 ii xdg-utils1.1.0~rc1+git20111210-6 Versions of packages deluge-gtk recommends: ii python-pygame 1.9.1release+dfsg-8 deluge-gtk 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#696837: [patch]
The file that imports libtorrent is packaged in deluge-common. Why do you think it should not have a dependency on it? What would be the right fix? On Fri, Jan 11, 2013 at 6:18 AM, Andrey Rahmatullin w...@wrar.name wrote: On Tue, Jan 08, 2013 at 12:17:58AM +1000, Eddy Pronk wrote: deluged has the dependency. The deluge-common package should have it instead. No, it shouldn't. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696837: [patch]
deluged has the dependency. The deluge-common package should have it instead. libtorrent.patch Description: Binary data
Bug#613686: Unplugging USB Headset freezes system
Package: pulseaudio Version: 0.9.21-3 If I plug in my Logitech USB Headset and remove it few seconds later the screen goes black and shows only the mouse pointer. It is not possible to open a console shell at this point. Power off is the only way out. If pulseaudio is removed from the system then this does not happen. Reinstalling pulseaudio brings back this problem. I'm running Debian Squeeze AMD 64 and did a fresh install after it was released as 6.0. Removing my user from the audio group does not have impact. (In Ubuntu 8.04 AMD64 this works fine on this laptop and same headset.) I found this in /var/log/messages Feb 16 13:49:01 popgun kernel: [12137.956302] usb 3-1: new full speed USB device using uhci_hcd and address 2 Feb 16 13:49:01 popgun kernel: [12138.165397] usb 3-1: New USB device found, idVendor=046d, idProduct=0a01 Feb 16 13:49:01 popgun kernel: [12138.165406] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Feb 16 13:49:01 popgun kernel: [12138.165412] usb 3-1: Product: Logitech USB Headset Feb 16 13:49:01 popgun kernel: [12138.165417] usb 3-1: Manufacturer: Logitech Feb 16 13:49:01 popgun kernel: [12138.165646] usb 3-1: configuration #1 chosen from 1 choice Feb 16 13:49:01 popgun kernel: [12138.325944] usbcore: registered new interface driver snd-usb-audio Feb 16 13:49:02 popgun pulseaudio[2141]: ratelimit.c: 164 events suppressed Feb 16 13:49:06 popgun pulseaudio[2141]: alsa-util.c: Got POLLNVAL from ALSA Feb 16 13:49:06 popgun pulseaudio[2141]: alsa-util.c: Could not recover from POLLERR|POLLNVAL|POLLHUP and XRUN: No such device
Bug#372769: patch aborts with pch.c:622: intuit_diff_type: Assertion `i0 != NONE' failed. (fwd)
The assert looks like a you should never get here condition.
It tries to figure out which filename should be used for the output.
At the point of the assert (or assume) it assumes at this point it
should be clear which filename to use.
This fails because we try to revert the patch but the file to apply it
to is not found. So there is nothing to revert to. In this case it is
fine to ignore the hunk.
My patch look very similar. I removed the assert because if it is part
of the if condition the assert condition can never be false.
I used a smaller file to reproduce it:
$ cat test.patch | patch -d . -R -E --dry-run -p2
missing header for unified diff at line 4 of patch
patch_: pch.c:622: intuit_diff_type: Assertion `i0 != NONE' failed.
Aborted (core dumped)
with the patch (see attachment reverse_bug.patch) it says:
missing header for unified diff at line 4 of patch
can't find file to patch at input line 4
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--
|diff -Nur test1/foo test2/foo
|--- test1/foo1970-01-01 10:00:00.0 +1000
|+++ test2/foo2007-08-27 20:54:30.0 +1000
--
File to patch:
Skip this patch? [y]
Skipping patch.
1 out of 1 hunk ignored
Eddy
diff -Nur patch-2.5.9.orig/pch.c patch-2.5.9/pch.c
--- patch-2.5.9.orig/pch.c 2007-08-26 17:56:57.0 +1000
+++ patch-2.5.9/pch.c 2007-08-29 07:23:16.0 +1000
@@ -617,9 +617,8 @@
}
is_empty = i == NONE || st[i].st_size == 0;
- if ((! is_empty) p_says_nonexistent[reverse ^ is_empty])
+ if (((! is_empty) p_says_nonexistent[reverse ^ is_empty]) (i0 != NONE))
{
- assert (i0 != NONE);
reverse ^=
ok_to_reverse
(The next patch%s would %s the file %s,\nwhich %s!,
diff -Nur test1/foo test2/foo
--- test1/foo 1970-01-01 10:00:00.0 +1000
+++ test2/foo 2007-08-27 20:54:30.0 +1000
@@ -0,0 +1 @@
+foo
