Bug#761445: Reported it

2014-09-25 Thread vitalif
OK, reported it as https://bugs.freedesktop.org/show_bug.cgi?id=84325 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#758096: tasksel: Allow to select specific packages during installation - just "DE", "Web server", "Mail server" is NOT enough

2014-08-14 Thread vitalif
Did you read the first reply in this thread? Not sure which one you're talking about... This one? https://lists.debian.org/debian-devel/2014/08/msg00130.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lis

Bug#738842: subversion: add debug package

2014-02-13 Thread vitalif
Package: subversion Version: 1.8.5-1 Severity: wishlist While I was trying to catch bug #738840 I've discovered there is no subversion-dbg package in Debian. Can you add it? As I understand it just requires adding package entry to control and --dbg-package=subversion-dbg to dh_strip (at least

Bug#738841: subversion: non-synchronized increment of cache->hit_count in libsvn_subr

2014-02-13 Thread vitalif
Package: subversion Version: 1.8.5-1 Severity: minor Tags: upstream There is also another bug Subversion 1.8 libsvn_subr - cache->hit_count and entry->hit_count are incremented without proper mutual exclusion (only with read lock), so some increments get lost in multithreaded svnserve; as it's

Bug#738840: subversion: integer overflow makes 32-bit svnserve hang sometimes

2014-02-13 Thread vitalif
Package: subversion Version: 1.8.5-1 Severity: normal Tags: upstream There is a bug in Subversion 1.8 libsvn_subr that makes 32-bit svnserve hang after some period of time doing an infinite loop inside ensure_data_insertable() because cache->data_used becomes a very big value after adding an u

Bug#737527: subversion: Replace GCJ by OpenJDK in Subversion JavaHL build

2014-02-13 Thread vitalif
Why do you request the use of OpenJDK given that GCJ is availale? :) It's better supported, and it's a lot faster; although the speed doesn't really matter for subversion build - only for tests maybe... And I don't think Oracle hegemony is really relevant since OpenJDK is also free software

Bug#725787: I've packaged svn 1.8.4 and serf 1.3.2 by myself

2013-11-15 Thread vitalif
FYI, locally also some tests were failing, but on the automated build machine for the PPA, the packages built just fine with all tests passing, not sure where the difference is here, but this was the same with 1.7.x versions of Subversion as well. I've updated the source package: 1) cleaned up s

Bug#725787: I've packaged svn 1.8.4 and serf 1.3.2 by myself

2013-11-11 Thread vitalif
Hello everyone! I've recently packaged svn 1.8.4 and serf 1.3.2 (which is needed by svn) by myself. I've never tried to perform any package maintenance, but I would be very happy if these packages could be reviewed in some way and taken as the base for real debian upload... So can you (someo

Bug#700333: Stack trace

2013-04-30 Thread vitalif
I merged a slightly better fix, you all were on cc. It's going into 3.10 and it's tagged stable, so it will show up in stable kernels soon. Thanks for the fix! But where did you post it - on LKML? (I didn't see it because I'm not subscribed to LKML?) -- To UNSUBSCRIBE, email to debian-bugs-dis

Bug#700333: Stack trace

2013-04-28 Thread vitalif
When you do a suspend/resume cycle. OK, yes, I've found it there. The bug says "The photo shows a BUG in hrtimer_interrupt() after making the hibernation image and while resuming the non-boot CPUs." so I'm guessing with Thomas' patch it suspends fine now? Yeah, now I'm using a patched kerne

Bug#700333: Stack trace

2013-04-27 Thread vitalif
Looks like we can't do anything about that in the HPET code itself. Vitaliy, could you try that patch ? Thanks, I've tried it several days ago (and still using a patched kernel :)) - the box survives. But at which moment should I check for "Spurious interrupt" in dmesg? -- To UNSUBSCRIBE, e

Bug#700333: Stack trace

2013-04-20 Thread vitalif
Stack trace picture is here: http://vmx.yourcmc.ru/var/pics/IMG_20130306_141045.jpg Vitaliy reported that his system crashes when suspending to disk. This was a regression from 3.2 to 3.7, and remains in 3.8. Some details of this system are in the bug log at .

Bug#703504: P.S: Reported it upstream

2013-03-20 Thread vitalif
P.S: I've reported this bug upstream as https://bugs.php.net/bug.php?id=64462 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#703504: libapache2-mod-php5: Statically linked libmagic in PHP 5.4 and 5.5 detects Visio as "application/msword"

2013-03-20 Thread vitalif
Package: libapache2-mod-php5 Version: 5.4.4-14 Severity: normal Dear Maintainer, PHP 5 has a statically linked patched libmagic included in it as a part of 'fileinfo' extension. It is 2 years old and has bugs. It would be good if PHP authors updated it and also submitted parts of their libmag

Bug#700333: Stack trace

2013-03-07 Thread vitalif
Hi Ben! Did the stack help you to identify something? "Enabling non-boot CPUs" seems suspicious to me - does that mean instead of writing an image to disk and hibernating it's trying to resume? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscr

Bug#700333: Stack trace

2013-03-06 Thread vitalif
No, but I think this kernel parameter will help: pause_on_oops= Halt all CPUs after the first oops has been printed for the specified number of seconds. This is to be used if your oopses keep scrolling off the screen

Bug#700333: Stack trace

2013-03-05 Thread vitalif
>It means nothing very much. How about the stack trace *before* this >line: The problem is that the maximum available VESA mode is 1400x1050 on my laptop and the stack is very long, and obviously I can't scroll it after a kernel panic :-) How can I get to previous lines of it? :-) There is ne

Bug#700333: Stack trace

2013-03-05 Thread vitalif
Hello I've booted with no_console_suspend and got the stack trace, however it's from 3.8-aptosid kernel. The problem with 3.8 is the same as with 3.7. Can someone please help me - what does this stack mean? Kernel panic - not syncing: Fatal exception in interrupt [ cut here ]

Bug#700333: Anyone?

2013-02-15 Thread vitalif
Anyone? The bug still persists in 3.7.8-1~experimental.1. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org