Bug#560920: [pkg-fgfs-crew] Bug#560937: Bug#560932: Bug#560912: Expat issues update
Mike Hommey skrev: > On Sun, Dec 13, 2009 at 05:21:26PM +0100, Matthias Klose wrote: >> On 13.12.2009 16:29, Michael Gilbert wrote: >>> Hi all, >>> >>> In order to guarantee that the system expat is used, the >>> '--with-expat=sys' configure argument must be used. If you think >>> your package is already using the system expat, or if you are updating >>> your package to use the system expat, please check to make sure that >>> this option is being used. Thanks. >> there's no such option for python, which uses a modified copy of expat. > > Likewise with mozilla, which uses a heavily modified copy of expat. And I think the xml parser in simgear was ripped from some version of mozilla. (Of course, I wouldn't consider a security flaw in a flight simulator library as critical as one in an actual web browser or anything, so I'm not sure how much I need to worry...) -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#555325: version 1.3.4 completely unusable
Package: gq Version: 1.3.4-1 > > Same as the first reporter. Just update gq yesterday in sid. it's totaly > unusable. > I'm trying to connect via ssl, I never find how to successfully do it. > ldapsearch is working smoothly, not gq. > > I can provide some backtrace of gtk backtraces produced under gdb. > > I confirm that the dn is forget evry time. > The port for ssl is not usuable in the old gq in host field I put before > : > ldaps://10.42.42.1/ and remove the port entry and it was working. > > Now, triggers a lot's of assert. > > I have tried with a LANG=C thinking of a problem with utf8 ... but > doens't seems to work better. > > Some time I've got random data in the dn field, making me thinking of a > buffer not rightly initialized or something like that. I just do a test using valgrind ... invalid read of already free'd memory ... so invalid pointers are there. Backtrace is not really usable ... : (one sample on 11). This happens when opening the preference box, then the local machine one. ==367==by 0x439DFA: ??? (in /usr/bin/gq) ==367==by 0x452178: ??? (in /usr/bin/gq) ==367==by 0x723F8FC: g_object_newv (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x72401AA: g_object_new_valist (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x72403FB: g_object_new (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x43AA38: ??? (in /usr/bin/gq) ==367==by 0x453E00: ??? (in /usr/bin/gq) ==367==by 0x72393EC: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x724CCDA: ??? (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x724E081: g_signal_emit_valist (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x724E552: g_signal_emit (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x52E7D54: ??? (in /usr/lib/libgtk-x11-2.0.so.0.1800.4) ==367==by 0x72393EC: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x724C5EB: ??? (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x724E081: g_signal_emit_valist (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x724E552: g_signal_emit (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x52E6A1C: ??? (in /usr/lib/libgtk-x11-2.0.so.0.1800.4) ==367==by 0x53973B7: ??? (in /usr/lib/libgtk-x11-2.0.so.0.1800.4) ==367==by 0x72393EC: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x724C9C8: ??? (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x724DF17: g_signal_emit_valist (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x724E552: g_signal_emit (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x54A05AD: ??? (in /usr/lib/libgtk-x11-2.0.so.0.1800.4) ==367==by 0x538F972: gtk_propagate_event (in /usr/lib/libgtk-x11-2.0.so.0.1800.4) ==367==by 0x5390A4A: gtk_main_do_event (in /usr/lib/libgtk-x11-2.0.so.0.1800.4) ==367==by 0x58BC35B: ??? (in /usr/lib/libgdk-x11-2.0.so.0.1800.4) ==367==by 0x76AF139: g_main_context_dispatch (in /lib/libglib-2.0.so.0.2200.3) ==367==by 0x76B2997: ??? (in /lib/libglib-2.0.so.0.2200.3) ==367==by 0x76B2E6C: g_main_loop_run (in /lib/libglib-2.0.so.0.2200.3) ==367==by 0x5390E46: gtk_main (in /usr/lib/libgtk-x11-2.0.so.0.1800.4) ==367==by 0x421747: ??? (in /usr/bin/gq) ==367==by 0x8574ABC: (below main) (libc-start.c:222) ==367== Address 0xd412c10 is 0 bytes inside a block of size 35 free'd ==367==at 0x4C21DBC: free (vg_replace_malloc.c:325) ==367==by 0x4380AC: ??? (in /usr/bin/gq) ==367==by 0x72393EC: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x724CCDA: ??? (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x724E081: g_signal_emit_valist (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x724E552: g_signal_emit (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x723D5F8: ??? (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x723C7E4: ??? (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x723C94A: g_object_thaw_notify (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x531B9CE: ??? (in /usr/lib/libgtk-x11-2.0.so.0.1800.4) ==367==by 0x531CE4B: gtk_entry_set_text (in /usr/lib/libgtk-x11-2.0.so.0.1800.4) ==367==by 0x439866: ??? (in /usr/bin/gq) ==367==by 0x439DFA: ??? (in /usr/bin/gq) ==367==by 0x452178: ??? (in /usr/bin/gq) ==367==by 0x723F8FC: g_object_newv (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x72401AA: g_object_new_valist (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x72403FB: g_object_new (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x43AA38: ??? (in /usr/bin/gq) ==367==by 0x453E00: ??? (in /usr/bin/gq) ==367==by 0x72393EC: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x724CCDA: ??? (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x724E081: g_signal_emit_valist (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x724E552: g_signal_emit (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==b
Processed: tagging 504973
Processing commands for cont...@bugs.debian.org: > # Automatically generated email from bts, devscripts version > 2.10.35lenny7~bpo40+1 > tags 504973 + squeeze sid Bug #504973 [libspiff] FTBFS with GCC 4.4: missing #include Added tag(s) sid and squeeze. > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#561089: ispell: segfaults on checking any file
Package: ispell Version: 3.1.20.0-7 Severity: grave Justification: renders package unusable When I try to spell check any file ispell simply segfaults. When I invoke it without arguments it prints the help text. To find out whether this was a recent regression I downgraded the package, but that did not help. This indicates that the cause may be unrelated to ispell. I also ran gdb on a core file from ispell, but the traceback did not reveal anything useful. Running strace in ispell shows that it uses curses to set up the terminal and then segfaults right after reading the file to be checked. Is there anything else I can do to help diagnose this? Helmut -- System Information: Architecture: amd64 (x86_64) Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages ispell depends on: ii dictionaries-common 1.4.0 Common utilities for spelling dict ii dpkg 1.15.5.4 Debian package management system ii ingerman [ispell-dictiona 20091006-2 New German orthography dictionary ii install-info 4.13a.dfsg.1-5 Manage installed documentation in ii libc6 2.10.2-2 GNU C Library: Shared libraries ii libncurses5 5.7+20090803-2 shared libraries for terminal hand Versions of packages ispell recommends: ii wamerican [wordlist] 6-3American English dictionary words ii wngerman [wordlist] 20091006-2 New German orthography wordlist -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#477211: lib32nss-mdns not present in Debian
lib32nss-mdns is not present in Debian repository, so the proposed solutions cannot be applied. A workaround is to lounch java application with the following parameter: -Djava.net.preferIPv4Stack=true The bug seem to be in the IPV6 implementation of libnss-msdn. I've found the workaround at this link: http://stackoverflow.com/questions/1608503/domain-name-resolution-not-working-in-java-applications-on-ubuntu64-9-04-machine -- Edy Incoletti Logic http://www.logicsistemi.it -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#559148: Confirmed
shambhala:~> LANG=C apt-get upgrade Reading package lists... Done Building dependency tree Reading state information... Done [...] The following packages will be upgraded: capisuite 1 upgraded, 0 newly installed, 0 to remove and 10 not upgraded. Need to get 0B/1107kB of archives. After this operation, 0B of additional disk space will be used. Do you want to continue [Y/n]? locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory Reading package fields... Done Reading package status... Done Retrieving bug reports... Done Parsing Found/Fixed information... Done Reading changelogs... Done (Reading database ... 356381 files and directories currently installed.) Preparing to replace capisuite 0.4.5-9 (using .../capisuite_0.4.5-10_i386.deb) ... Stopping capisuite daemon: capisuite. dpkg (subprocess): unable to execute new pre-installation script: Exec format error dpkg: error processing /var/cache/apt/archives/capisuite_0.4.5-10_i386.deb (--unpack): subprocess new pre-installation script returned error exit status 2 insserv: warning: current start runlevel(s) (empty) of script `capisuite' overwrites defaults (2 3 4 5). [...] Errors were encountered while processing: /var/cache/apt/archives/capisuite_0.4.5-10_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) This is the preinst scrip in the new package 0.4.5-10: shambhala:~> cat /tmp/preinst # TODO: remove this file after releasing Squeeze set -e if [ "$1" = upgrade ] && dpkg --compare-versions "$2" lt 0.4.5-10 then pycentral pkgremove python-foo fi This is the existing preinst script from 0.4.5-9: shambhala:~> cat /var/lib/dpkg/info/capisuite.preinst #!/bin/sh set -e # Automatically added by dh_pycentral case "$1" in install|upgrade) mkdir -p /var/lib/pycentral echo '# the presence of this file allows calling pkgremove on upgrade' \ > /var/lib/pycentral/capisuite.pkgremove esac # End automatically added section Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 signature.asc Description: This is a digitally signed message part.
Bug#561089: ispell: segfaults on checking any file
On Mon, Dec 14, 2009 at 02:03:35PM +0100, Helmut Grohne wrote: > Package: ispell > Version: 3.1.20.0-7 > Severity: grave > Justification: renders package unusable > > When I try to spell check any file ispell simply segfaults. When I > invoke it without arguments it prints the help text. To find out whether > this was a recent regression I downgraded the package, but that did not > help. This indicates that the cause may be unrelated to ispell. I also > ran gdb on a core file from ispell, but the traceback did not reveal > anything useful. Running strace in ispell shows that it uses curses to > set up the terminal and then segfaults right after reading the file to > be checked. > > Is there anything else I can do to help diagnose this? That seems related to this ingerman installation error Unpacking ingerman (from .../ingerman_20091006-2_all.deb) ... Setting up ingerman (20091006-2) ... ispell-autobuildhash: Processing 'ngerman' dict Hash table overflowed by 1342 words Does this happen with other dictionaries? -- Agustin -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
capisuite 0.4.5-10 MIGRATED to testing
FYI: The status of the capisuite source package in Debian's testing distribution has changed. Previous version: 0.4.5-9 Current version: 0.4.5-10 -- This email is automatically generated once a day. As the installation of new packages into testing happens multiple times a day you will receive later changes on the next day. See http://release.debian.org/testing-watch/ for more information. -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#557980: Please provide steps to get to the segfault
Ok, I figured out what happened and I feel pretty old for not remembering that I had already reported this problem and been involved in the fix. It turns out that this is a regression of bug 412102. 64 bit environments require a different file than 32. James On Sunday 29 November 2009 04:04:34 pm you wrote: > On Sun, Nov 29, 2009 at 03:21:08PM -0500, James Umbanhowar wrote: > > One example: > > > > xppaut /usr/share/doc/xppaut/examples/ode/nochaos.ode > > > > once it starts, I type "i" of integrate and "g" for go and then it > > segfaults. > > > > James > > Hm doesn't have any troubles for me. Maybe someone else can > reproduce this? Additionally perhapes you can produce a packatrace > after building a debug package and running the failed stuff in gdb? > [0] tells how to do so. > > Regards > > Christoph > > [0] > http://jameswestby.net/tips/tips/compiling-debian-package-for-debug.html > -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#561089: ispell: segfaults on checking any file
On Mon, 14 Dec 2009, Agustin Martin wrote: > On Mon, Dec 14, 2009 at 02:03:35PM +0100, Helmut Grohne wrote: > > Package: ispell > > Version: 3.1.20.0-7 > > Severity: grave > > Justification: renders package unusable > > When I try to spell check any file ispell simply segfaults. When I > > invoke it without arguments it prints the help text. To find out > > whether this was a recent regression I downgraded the package, but > > that did not help. This indicates that the cause may be unrelated > > to ispell. I also ran gdb on a core file from ispell, but the > > traceback did not reveal anything useful. Running strace in ispell > > shows that it uses curses to set up the terminal and then > > segfaults right after reading the file to be checked. > > Is there anything else I can do to help diagnose this? > That seems related to this ingerman installation error > > Unpacking ingerman (from .../ingerman_20091006-2_all.deb) ... > Setting up ingerman (20091006-2) ... > ispell-autobuildhash: Processing 'ngerman' dict > Hash table overflowed by 1342 words I can reproduce the problem here. It seems to be a problem in buildhash. Function filltable() from buildhash.c throws this error message when I try to build the ngerman hash file: $ gzip -dc /usr/share/ispell/ngerman.mwl.gz > /tmp/ngerman.mwl $ buildhash -s /tmp/ngerman.mwl /usr/lib/ispell/ngerman.aff /tmp/ngerman.hash Hash table overflowed by 1371 words With some sorting and tweeking on ngerman.mwl I can change the number of overflowed words but I wasn't able to reduce this to zero. > Does this happen with other dictionaries? I know that this didn't happen with the old 20071211 ngerman dictionary, but the upstream maintainer of this dictionary was quite active and introduced many changes in 20091006 version. I didn't understand why this hash table overflow in buildhash implies the segmentation fault of ispell, but I can reproduce the problem here. I would expect a behavior where only some words are missing... I just tried out whether buildhash from ispell 3.3.0.2 behaves different, but I get the same error message there. Do you see a chance to increase the size of the hash table to get rid of this problem? Or do we have to modify the German dictionary to fit into the data structure (but where should I start with skipping words?). Removing just some thousand lines from the end of the input file doesn't solve the problem, so maybe not the number of lines but some special lines seem to trigger the problem. But what lines? Tscho Roland -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Processed: Re: Bug#561089: ispell: segfaults on checking any file
Processing commands for cont...@bugs.debian.org: > severity 561089 important Bug #561089 [ispell] ispell: segfaults on checking any file Severity set to 'important' from 'grave' > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#561089: ispell: segfaults on checking any file
I wrote: > I know that this didn't happen with the old 20071211 ngerman > dictionary, but the upstream maintainer of this dictionary was quite > active and introduced many changes in 20091006 version. > > I didn't understand why this hash table overflow in buildhash implies > the segmentation fault of ispell, but I can reproduce the problem > here. I would expect a behavior where only some words are missing... > > I just tried out whether buildhash from ispell 3.3.0.2 behaves > different, but I get the same error message there. > > Do you see a chance to increase the size of the hash table to get rid > of this problem? Or do we have to modify the German dictionary to fit > into the data structure (but where should I start with skipping > words?). Removing just some thousand lines from the end of the input > file doesn't solve the problem, so maybe not the number of lines but > some special lines seem to trigger the problem. But what lines? In the meantime I found out, that my recent 20091006-2 package did not run munchlist over the mwl file (don't ask me why). After doing this again, buildhash no longer has problems building the hash. I just uploaded a fixed igerman98 20091006-3 to the archive. So I think that the severity of this bug report can be decreased. Nevertheless it is IMHO a bug that buildhash can run into such a trouble that ispell segfaults when it uses the dictionaries... Tscho Roland -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#119888: Patch for fix that
In this reference [http://wiki.nginx.org/ThttpdRealIP] is avaliable a
patch for that thttpd respect the X-forward-for header (originaly posted
by Daniel Clemente [http://www.danielclemente.com/amarok/ip_real.txt] ).
I would like you apply this patch. I add now:
--- thttpd-2.25b/libhttpd.c 2003-12-25 20:06:05.0 +0100
+++ thttpd-2.25b-patched/libhttpd.c 2005-01-09 00:26:04.867255248 +0100
@@ -2207,6 +2207,12 @@
if ( strcasecmp( cp, "keep-alive" ) == 0 )
hc->keep_alive = 1;
}
+ else if ( strncasecmp( buf, "X-Forwarded-For:", 16 ) == 0 )
+ { // Use real IP if available
+ cp = &buf[16];
+ cp += strspn( cp, " \t" );
+ inet_aton( cp, &(hc->client_addr.sa_in.sin_addr) );
+ }
#ifdef LOG_UNKNOWN_HEADERS
else if ( strncasecmp( buf, "Accept-Charset:", 15 ) == 0 ||
strncasecmp( buf, "Accept-Language:", 16 ) == 0 ||
I CC acme labs software for confirming this bug is _not_ fixed in
version 2.22 (or any later version) of thttpd (in
http://acme.com/software/thttpd/#releasenotes it seems it's not) and
Daniel Clemente for knowing your work is helpful for others ;-) (I hope
you're not "molesto", Daniel)
Thanks a lot,
Xan.
--
To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#561089: ispell: segfaults on checking any file
severity 561089 important thanks Thanks for all your work on this bug. I also observed that languages other than german work well with ispell. (Answer to some question in this thread.) On Mon, Dec 14, 2009 at 08:49:32PM +0100, Roland Rosenfeld wrote: > In the meantime I found out, that my recent 20091006-2 package did not > run munchlist over the mwl file (don't ask me why). After doing this > again, buildhash no longer has problems building the hash. > I just uploaded a fixed igerman98 20091006-3 to the archive. Thanks! > So I think that the severity of this bug report can be decreased. > Nevertheless it is IMHO a bug that buildhash can run into such a > trouble that ispell segfaults when it uses the dictionaries... Done. Helmut -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#560940: CVE-2009-3560 and CVE-2009-3720 denial-of-services
I'm having a look at this. I had worked on this package a while ago, and I'm currently doing a NM Tasks&Skills, so it's a pleasure ;) -- Sylvain signature.asc Description: Digital signature
