Bug#714571: closed by Ben Hutchings (Re: Bug#714571: linux-image-3.10-rc7-686-pae: linux-kbuild-3.10 not available)
Oh, sorry, of course linux-image doesn't. Thank you for clarifying, so this is an expected situation; it still seems slightly odd for me, because drives the repository into an inconsistent state though. But OK if it's by intention.
Bug#658075: 2.63a-2 has incorrect dependency on libpng15-15
Please reopen this bug! Maybe it's fixed in 2.63a-2, but nobody can install it via apt-get because it has incorrect dependency on unavailable package libpng15-15. :)
Bug#588507: I would also appreciate the new version of avra in Debian
I would also appreciate the new version of avra in Debian. Please update it :-)
Bug#622591: Probably libc6, not gcc...
Thanks for the quip, I found it :) It's probably libc6, not gcc... See libc6 Bug 12453 - Broken thread local storage (TLS) initialization http://sourceware.org/bugzilla/show_bug.cgi?id=12453 See also: https://bugs.gentoo.org/353224 https://github.com/cschwan/sage-on-gentoo/issues/40 There is a test script demonstrating the error: http://sourceware.org/bugzilla/attachment.cgi?id=5218 Checked it, it fails on my system. So, probably, that's it. I've submitted Debian Bug 637239: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=637239 -- With best regards, Vitaliy Filippov -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#637239: libc6: Broken thread local storage (TLS) initialization
Package: libc6 Version: 2.13-7 Severity: important Tags: upstream There is a bug with TLS in libc6, beginning with 2.12. See libc6 Bug 12453 - Broken thread local storage (TLS) initialization http://sourceware.org/bugzilla/show_bug.cgi?id=12453 There is a test script demonstrating the segfault: http://sourceware.org/bugzilla/attachment.cgi?id=5218 It also affects Debian Bug 622591 (SEGV with libuuid and imagemagick). See also: https://bugs.gentoo.org/353224 https://github.com/cschwan/sage-on-gentoo/issues/40 -- System Information: Debian Release: wheezy/sid APT prefers oldstable APT policy: (500, 'oldstable'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.38-2-686-bigmem (SMP w/2 CPU cores) Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R) (ignored: LC_ALL set to ru_RU.KOI8-R) Shell: /bin/sh linked to /bin/bash Versions of packages libc6 depends on: ii libc-bin 2.13-7 Embedded GNU C Library: Binaries ii libgcc1 1:4.6.0-11 GCC support library Versions of packages libc6 recommends: ii libc6-i6862.13-7 Embedded GNU C Library: Shared lib Versions of packages libc6 suggests: ii debconf [debconf-2.0] 1.5.40 Debian configuration management sy ii glibc-doc 2.13-7 Embedded GNU C Library: Documentat ii locales 2.13-7 Embedded GNU C Library: National L -- debconf-show failed -- With best regards, Vitaliy Filippov
Bug#622591: Backtrace & thread-localness
My backtrace: Program received signal SIGSEGV, Segmentation fault. 0xb639f382 in get_random_fd () at gen_uuid.c:156 156 jrand_seed[0] = getpid() ^ (tv.tv_sec & 0x); (gdb) bt #0 0xb639f382 in get_random_fd () at gen_uuid.c:156 #1 0xb63a0678 in uuid_generate (out=0xa95f3d0 "") at gen_uuid.c:669 #2 0xb5cce704 in ChertVersion::create (this=0xa95f3cc) at ../backends/chert/chert_version.cc:73 #3 0xb5c9c4f7 in ChertDatabase::create_and_open_tables (this=0xa95f3b8, block_size=8192) at ../backends/chert/chert_database.cc:195 #4 0xb5ca166f in ChertDatabase::ChertDatabase (this=0xa95f3b8, chert_dir=..., action=1, block_size=8192) at ../backends/chert/chert_database.cc:144 #5 0xb5ca1c04 in ChertWritableDatabase::ChertWritableDatabase (this=0xa95f3b8, dir=..., action=1, block_size=8192) at ../backends/chert/chert_database.cc:1027 #6 0xb5c459a9 in Xapian::WritableDatabase::WritableDatabase (this=0xa76c450, path=..., action=1) at ../backends/dbfactory.cc:480 #7 0xb5e54893 in XS_Search__Xapian__WritableDatabase_new1 (my_perl=0x81a7008, cv=0xa5c657c) at ./XS/WritableDatabase.xs:11 #8 0x080e3c63 in Perl_pp_entersub (my_perl=0x81a7008) at pp_hot.c:2888 #9 0x080db232 in Perl_runops_standard (my_perl=0x81a7008) at run.c:40 #10 0x08081c7c in S_run_body (my_perl=0x81a7008) at perl.c:2303 #11 perl_run (my_perl=0x81a7008) at perl.c:2233 #12 0x080657af in main (argc=4, argv=0xb064, env=0xb078) at perlmain.c:117 (gdb) print jrand_seed Cannot access memory at address 0x4 jrand_seed is declared thread-local in the source. If you make it non-TLS, the segfault also goes away... So, does this mean that ImageMagick corrupts thread-local storage in some way? -- With best regards, Vitaliy Filippov -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#622591: I also confirm this bug
Oops, sorry. 6.7.1 also fails, but in some different situation... Previous test runs without SIGSEGV in 6.7.1. I haven't found the new test yet. It's curious that if you specify LD_PRELOAD=/lib/libuuid.so.1 on the command line, the segmentation fault goes away completely. -- With best regards, Vitaliy Filippov -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#622591: I also confirm this bug
I also confirm this bug. In my case, however, a separate perl module
(T.pm) with a function must be used to reproduce the bug. Just calling
Search::Xapian::WritableDatabase->new() from the test script doesn't work.
This is probably an ImageMagick bug, just because it doesn't happen with
6.7.1 built from the source. (the bug happens on ImageMagick 6.6.9-7-5)
So please, just update ImageMagick package to 6.7.1.
t.pl:
require Image::Magick;
require T;
T::test();
T.pm:
package T;
use Search::Xapian qw(:db);
sub test {
my $xap = Search::Xapian::WritableDatabase->new('./xapian', DB_CREATE);
print "OK\n";
}
1;
--
With best regards,
Vitaliy Filippov
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#613403: reopened: hg clone fails with https site behind an http proxy
What environment variables are you using? To what are you setting them? Are you using any extensions? hgsubversion is known to ignore http_proxy, for example. No, I'm not using any extensions, I simply clone a googlecode HG repository. This is very strange, I also could not reproduce this bug on other machine that has direct Internet access. This runs OK: iptables -A OUTPUT -p tcp --dport 443 -j DROP http_proxy=http://95.31.10.190:3128 https_proxy=http://95.31.10.190:3128 strace hg clone https://mediawiki4intranet.googlecode.com/hg/ mediawiki4intranet But when I'm trying this at work (proxy.custis.ru:3128 is an intranet proxy, port 443 is closed on the router), it fails and strace looks very strange - it seems hg connects to the proxy and starts tunnel connection, but then also tries to connect directly (see attached strace.gz). This command fails: http_proxy=http://proxy.custis.ru:3128/ https_proxy=http://proxy.custis.ru:3128/ hg clone https://mediawiki4intranet.googlecode.com/hg/ mediawiki4intranet -- With best regards, Vitaliy Filippov strace.gz Description: GNU Zip compressed data
Bug#613403: reopened: hg clone fails with https site behind an http proxy
Package: mercurial Version: 1.7.3-1 Severity: normal Mercurial fails to clone from https site being behind an http proxy. Environment variables are set correctly. Mercurial first connects to proxy, but then also tries to open direct connection and fails. So this is probably a reopened Bug 498711. Reproduces in mercurial 1.6 and 1.7. How to reproduce: simply set up an http CONNECT proxy and try to clone some code.google.com repository from behing it. -- System Information: Debian Release: squeeze/sid APT prefers stable APT policy: (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.36-trunk-686-bigmem (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to ru_RU.UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages mercurial depends on: ii libc6 2.11.2-7 Embedded GNU C Library: Shared lib ii mercurial-common1.7.3-1 scalable distributed version contr ii python 2.6.6-3+squeeze1 interactive high-level object-orie ii python-support 1.0.11 automated rebuilding support for P ii ucf 3.0025+nmu1 Update Configuration File: preserv mercurial recommends no packages. Versions of packages mercurial suggests: ii kdiff3 0.9.95-7compares and merges 2 or 3 files o pn qct(no description available) ii tk8.4 [wish] 8.4.19-4Tk toolkit for Tcl and X11, v8.4 - ii tk8.5 [wish] 8.5.8-1 Tk toolkit for Tcl and X11, v8.5 - ii vim-gnome [v 2:7.3.035+hg~8fdc1210-1 Vi IMproved - enhanced vi editor - -- Configuration Files: /etc/mercurial/hgrc.d/mergetools.rc [Errno 2] Нет такого файла или каталога: u'/etc/mercurial/hgrc.d/mergetools.rc' -- 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#563602: I had a similar issue
Hi! The problem was much simpler: I had partially broken hardware (RAM module) on that server =) Database corruption was probably caused simply by some changes of memory read/write activity on the resync under load. All the same, thank you for the answer! And sorry for incorrect bug report :) -- With best regards, Vitaliy Filippov -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#563602: I had a similar issue
Hi! I was running MySQL InnoDB databases on mdadm RAID5 partition with XFS file system when I discovered that if /etc/cron.d/mdadm (checkarray) of this partition concurs with some database updates, database file is corrupted and needs some kind of recovery, which is not always simple. This bug does reproduce on my server with, for example, on FeedOnFeeds database (server-side rss aggregator) when it's cronjob is updating rss feeds. RAID array, though, does not degrade, and it seems that MyISAM (non-transactional) tables are OK even when checkarray concurs with database updates. So I suppose the data loss is caused by some sync/barrier issues... Is that so? And if so, what I'm supposed to do to get rid of this problem? -- With best regards, Vitaliy Filippov -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#535479: php-openid: .*? in _tag_expr in Parse.php causes openid.server 's not parsed on some pages
Package: php-openid Version: 2.1.3-1 Severity: important Tags: patch *** Please type your report below this line *** In Auth/OpenID/Parse.php, $_tag_expr regexp is "<%s\b(?!:)([^>]*?)(?:\/>|>(.*?)(?:<\/?%s\s*>|\Z))". And libpcre3's implementation of .*? is probably recursive. So, on big HTML pages with , like http://stas-fomin.blogspot.com/, ... tag is not matched due to a stack overflow during matching of .*? (matching stops after approximately 99264 bytes). So, Auth_OpenID does not work with these pages. A workaround is very simple: change .*? to .* A patch is attached. -- System Information: Debian Release: squeeze/sid APT prefers oldstable APT policy: (500, 'oldstable'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.30-1-686 (SMP w/2 CPU cores) Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R) Shell: /bin/sh linked to /bin/bash Versions of packages php-openid depends on: ii php5 5.2.10.dfsg.1-1 server-side, HTML-embedded scripti ii php5-curl5.2.10.dfsg.1-1 CURL module for php5 ii php5-gmp 5.2.10.dfsg.1-1 GMP module for php5 php-openid recommends no packages. Versions of packages php-openid suggests: pn php-db (no description available) -- no debconf information -- Wbr, Vitaliy Filippov Parse.php.diff Description: Binary data
Bug#520246: php5-common: libxml2 2.7.3.dfsg-1 causes tags and entity references in entities to be not parsed
Package: php5-common
Version: 5.2.6.dfsg.1-3
Severity: important
Description:
When using PHP's internal xml parser (xml_parser_create) linked to libxml2,
standard entity references ("<", ">", "'", """, "&") are
all cut off and not passed to character_data_handler.
All is good with libxml2 2.6.32.dfsg-5. Instead, this is caused by "voodoo code"
in PHP. See links below:
php.net bug: http://bugs.php.net/bug.php?id=45996
("libxml2 2.7.1 causes breakage with character data in xml_parse()")
Mandriva bug: https://qa.mandriva.com/show_bug.cgi?id=43486
Reproduce code (PHP):
$xml = <<------&---"---
HERE;
$parser = xml_parser_create('UTF-8');
xml_set_character_data_handler($parser, 'cdata');
xml_parse($parser, $xml);
function cdata($parser, $data)
{
print "$data\n";
}
?>
Expected results:
---
<
test
---
&
---
"
---
Actual results:
---
test
---
---
---
-- System Information:
Debian Release: squeeze/sid
APT prefers oldstable
APT policy: (500, 'oldstable'), (500, 'unstable'), (500, 'stable'), (1,
'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R)
Shell: /bin/sh linked to /bin/bash
Versions of packages php5-common depends on:
ii libc6 2.9-4 GNU C Library: Shared libraries
ii sed 4.1.5-8The GNU sed stream editor
php5-common recommends no packages.
php5-common suggests no packages.
-- no debconf information
--
With best regards,
Vitaliy Filippov
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#472647: mod-perl 2.0.2-2.4 (etch version) also does segfault with PerlOptions +Parent
I think it's also related to this bug. When you try to set "PerlOptions +Parent" in some enabled vhost, httpd segfaults on any command. mod-perl 2.0.4-5 does not; indeed, Etch has 2.0.2-2.4 so you couldn't use +Parent on etch... (I solved this problem building 2.0.4-5 debs from dpkg-source on Etch) Sorry for probably messy English. -- Best regards, Vitaliy Filippov -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
