Bug#982247: Copyright file cites wrong version of text

Package: bible-kjv Severity: minor The `debian/copyright' file says: : The copyright for the King James Version text of the Bible is expired since : the translation was done in 1611 under King James the first of Great : Britain. But `bible.rawtext' doesn't contain the 1611 text. For example,

Bug#982246: `lovingkindness' is spelled thus, as one word, in the 1769 text

Package: bible-kjv-text Version: 4.10 Severity: normal The submitter of bug #120156 said: : bible(KJV) [Gen1:1]> Ps 92:2 : : Psalms 92 : : 2 To shew forth thy lovingkindness in the morning, and thy faithfulness every : night, : bible(KJV) [Ps92:2]> quit : : ^

Bug#963490: groff: /etc/groff/*.local override of `tty: sgr' is undocumented

Package: groff Version: 1.22.4-3 Severity: minor The Groff documentation is fairly adamant that the default behaviour for text output is to use control-characters for highlighting. For example, grotty(1): By default, grotty emits SGR escape sequences (from ISO 6429, also

Bug#959396: pterm +ut creates a defunct process (#165887, slight return)

Package: pterm Version: 0.70-6 Severity: minor Tags: patch upstream It looks superficiallu like #165887 is back: [spirit ~]ls -l .putty/sessions total 0 [spirit ~]pterm +ut& [1] 11172 [spirit ~]echo $! 11172 [spirit ~]ps f PID TTY STAT TIME COMMAND

Bug#929960: libfluidsynth1: Sample rate capped at 96kHz; causes bad output when JACK running at 192kHz

Package: libfluidsynth1 Version: 1.1.6-4 Severity: normal Tags: patch When recording, I run JACK with a 192kHz sample rate, to match my audio interface, so as to minimize the cumulative errors through the audio processing chain. Fluidsynth-based instruments appear to work, but produce

Bug#875285: python-pyrex: returning from exception handler causes segfault

Package: python-pyrex Version: 0.9.9-1 Severity: normal [crybaby /tmp/mdw]cat t.pyx ### -*-pyrex-*- def test(x): try: return int(x) except TypeError: return 'failed' [crybaby /tmp/mdw]pyrexc t.pyx && gcc -fPIC -Og -g -c -I/usr/include/python2.7 t.c && ld -shared -otmodule.so t.o -lpython2.7

Bug#875284: python-pyrex: Exception handling doesn't clear exceptions

Package: python-pyrex Version: 0.9.9-1 Severity: normal [crybaby /tmp/mdw]cat t.pyx ### -*-pyrex-*- def test(x): try: return int(x) except TypeError: pass return 'failed' [crybaby /tmp/mdw]cat u.py ### -*-python-*- import t def p(x): y = t.test(x) print '%r -> %r' % (x, y) for i in

Bug#868366: python2.7: Exports `md5_init', causing conflicts with extension modules

Matthias Klose writes: > python uses _init for extension modules / builtins to > initilize these. So it's part of the ABI as well. Not sure how to > change that. No, it uses `initMODULE' for that: : :

Bug#868366: python2.7: Exports `md5_init', causing conflicts with extension modules

Package: python2.7 Version: 2.7.13-2 Severity: normal [stratocaster ~]nm --dynamic /usr/bin/python2.7 | grep md5 00091732 T init_md5 001d6890 T md5_append 001d67d0 T md5_finish 000919f3 T md5_init [stratocaster ~] This causes trouble when trying to use bindings to a crypto library which also

Bug#715271: Preprocessor now handles _Pragma less badly

I've recently upgraded to stretch (from wheezy), and I thought I'd look to see whether my compiler bugs have been fixed. This one is half fixed. Specifically, the integrated preprocessor now seems to work the same way as the separate one, so the second example program, which I named

Bug#715262: Fixed while I wasn't looking

I've recently upgraded to stretch (directly from wheezy) and I thought I'd see if my compiler bugs had been fixed. And this one has been to my satisfaction. Feel free to mark this bug fixed in gcc 4:6.3.0-4. -- [mdw]

Bug#866964: Fwd: mpi_set_secure leads to heap corruption

NIIBE Yutaka writes: > Thank you for forwarding the bug report. > > Fixed both for master and LIBGCRYPT-1-7-BRANCH. Thanks. > Yes. While the patch is right, I followed the suggestion for less > surprise. Fair enough. > While there is the API, I don't know the real use

Bug#867189: dgit: Confusing error trying to fetch libgcrypt20 security updates

Package: dgit Version: 3.10 Severity: normal I suspect the following shouldn't happen. (It also happens without the environment laundering, and on chiark (jessie).) [stratocaster /tmp/mdw]rm -rf t.dgit && mkdir t.dgit && env - HOME=/notexist XDG_CACHE_DIR=$(pwd)/t.dgit PATH=/bin:/usr/bin dgit

Bug#867185: dgit: Perl error trying to clone Gtk+

Package: dgit Version: 3.10 Severity: normal The transcript below demonstrates the problem. I get the same failure on chiark (jessie), with a clean environment and bogus $HOME (to eliminate my dotfiles). [stratocaster /tmp/mdw]dgit clone gtk+3.0 canonical suite name for unstable is sid starting

Bug#866964: libgcrypt20: mpi_set_secure leads to heap corruption

Package: libgcrypt20 Version: 1.7.6-2+deb9u1 Severity: normal Tags: patch The function `mpi_set_secure' is used by `gcry_mpi_set_flag' to convert an integer so as to use `secure' (i.e., locked, non-swappable) memory. It's broken. The code in 1.7.8 (sid) is the same, so that's broken too.

Bug#865985: sync-accounts: Fails on startup with Perl syntax error

Package: chiark-utils Version: 5.0.2 Severity: normal Tags: patch $ sync-accounts Can't use 'defined(@array)' (Maybe you should just omit the defined()?) at ./sync-accounts line 67. Apparently this isn't allowed any more. perl5220delta(1) says: :"defined(@array)" and "defined(%hash)" are

Bug#865980: prayer: Support overriding prayer's URL prefix

Package: prayer Version: 1.3.5-dfsg1-4 Severity: wishlist Tags: patch When running prayer behind a reverse-proxy, it's useful to override prayer's internally generated guess as to its outward-facing URL. For example, maybe the proxy terminates TLS, so prayer looks externally as if it's behind an

Bug#473856: closed by Andreas Beckmann a...@debian.org (closing bugs reported against ancient emacs versions)

ow...@bugs.debian.org (Debian Bug Tracking System) writes: This is an automatic notification regarding your Bug report which was filed against the emacs22-common-non-dfsg package: #473856: emacs22-common-non-dfsg: Would be nice to provide printable docs (PS or PDF) It has been closed by

Bug#788783: openssh-client: uses MD5 for key fingerprints

brian m. carlson sand...@crustytoothpaste.net writes: The remaining possibility is that the adversary has managed to come up with a new public key (and matching private key) with the same fingerprint as the target key, which was generated by an honest party. But that's finding a second

Bug#788783: openssh-client: uses MD5 for key fingerprints

brian m. carlson sand...@crustytoothpaste.net writes: MD5 is not suitable for any application requiring collision resistance, such as a key fingerprint. Please switch to one of the SHA-2 values instead, or upgrade to OpenSSH 6.8, which fixes this problem. Fortunately, your premise is

Bug#748255: openssh-client: If VerifyHostKeyDNS is set, HostKeyAlgorithms should prefer algorithms with (comprehensible) SSHFP records

Package: openssh-client Version: 1:6.0p1-4+deb7u1 Severity: normal The version of ssh in wheezy has incomplete support for ECDSA keys. In particular, it doesn't know how to construct or verify SSHFP records for them (dns.c, dns_read_key). If we're going with the default HostKeyAlgorithm

Bug#743163: Patch

, for +#743163. + + -- Mark Wooding m...@distorted.org.uk Fri, 09 May 2014 17:58:18 +0100 + quota (4.00-4+deb7u1) testing-proposed-updates; urgency=low * Non-maintainer upload. diff --git a/debian/quota.init b/debian/quota.init index ccf60f9..53f1630 100644 --- a/debian/quota.init +++ b/debian

Bug#742513: Untested patch

I've just thrown together a patch. It compiles but is otherwise entirely untested! I'm interested in comments like `No, that's the wrong fix: you should do mumble instead.' diff --git a/sshconnect.c b/sshconnect.c index 87c3770..dfe44e4 100644 --- a/sshconnect.c +++ b/sshconnect.c @@ -1218,36

Bug#741101: ebtables: Misparses locally-originated multicast frames

Package: src:linux Version: 3.2.51-1 Severity: normal I was beefing up the filtering on a VM host, to do source-address checking on outbound packets when I noticed these surprising log messages from the kernel (reformatted for easier reading). | 2014-03-08T13:03:57+00:00 fender kernel:

Bug#645292: Patch for ancient bug

Amazingly, this bug still hasn't been fixed. Or even commented upon by the maintainer (who has anyway uploaded new upstream versions which don't fix the bug in the meantime). Here's a slightly ugly patch which I think is correct. I'm using this now. --- CIDR.pm 2012-02-15

Bug#715262: Spurious -Warray-bounds warning

Package: gcc Version: 4:4.7.2-1 Consider the following program. [gibson /tmp/mdw]cat arr.c int foo(const int *p, unsigned sz) { unsigned i; int v[5]; int x; for (i = 0; i sz; i++) v[i] = *p++; x = v[i - 1]; for (; i 1; i++) x -= 1; return (x); } [gibson /tmp/mdw]gcc -c -O2

Bug#715271: Preprocessor handles _Pragma badly

Package: gcc Version: 4:4.7.2-1 The `_Pragma' keyword is handled badly by GCC's preprocessor. Consider the following program, which is a simplified version of a warning suppression framework and a test case. #include stdio.h #define PRAGMA(x) _Pragma(#x) #define WARNING(warn) PRAGMA(GCC

Bug#692247: getGenre() API call prints boo on the console

Package: python-eyed3 Version: 0.6.18-1 Followup-For: Bug #692247 There are two `print boo' lines in `tag.py'. Joseph Nahmias's patch only removes one of them. Below is a patch which fixes both. --- tag.py.orig 2013-05-25 20:06:01.0 +0100 +++ tag.py 2013-05-25 20:06:33.0

Bug#663280: Updated patch against 1.3.7

Now that wheezy's been released -- without the patch I submitted over a year ago -- I have to fix all of my machines again, so I've respun the patch, and here it is. Not that I have a great deal of hope that submitting it here will actually cause anything to happen. Index:

Bug#663280: Updated patch against 1.3.7

Ondrej Zajicek santi...@crfreenet.org writes: See following code in nl_parse_link() in sysdep/linux/netlink.c : [...] if (ifi strncmp(ifi-name, name, sizeof(ifi-name)-1)) if_delete(ifi); Yes, I see. That ought to do it, if you're sure that this is a Linux- specific problem.

Bug#686449: userv: Parser unable to parse `range' condition

Package: userv Version: 1.0.5-0.2 Severity: normal The `range' condition can never be parsed successfully. You get an error found keyword `1000', expected linear whitespace instead. The bug is in `parser.c'. The function `pa_mwsp' insists on parsing some whitespace; `pa_numberdollar'

Bug#663280: bird: Fails to track state of interfaces past a change of name

Package: bird Version: 1.3.6-1 Severity: normal Tags: patch I have a VPN which creates and tears down tunnel interfaces as peers arrive and depart; to help keep things straight, particularly with firewall rules, the VPN renames its interfaces after the peer associated with the interface, rather

Bug#660276: ckermit: Segfault when reading \v(dialmessage)

Package: ckermit Version: 302-1 Severity: normal Run `kermit -C echo \v(dialmessage)'. You get a segfault while trying to print `\v(dialstate)'. What's happening? `dialsta' is initialized to DIA_UNK = -1 (ckudia.c), and then used to index an array of strings `dialmsg' (nvlook, ckuus4.c). I

Bug#660066: pty opening completely broken

Package: ckermit Version: 211-15 Severity: normal This build of ckermit can't open ptys. If you try, you just get a blank line (not even an error!). (/home/mdw/) C-Kermitpty true (/home/mdw/) C-Kermit What's going on? strace says: write(1, \n, 1) = 1

Bug#656398: strace overwrites useful core files with its own useless ones

Package: strace Version: 4.5.20-2.3 Severity: normal Suppose I run a buggy program under strace. [vampire /tmp/mdw/strace-bug]strace -ospew sh -c 'kill -SEGV $$' Segmentation fault (core dumped) That's nice. Now I can debug my program using the core dump to tell me what state it was in, and

Bug#654599: grub-common: Create/chmod race in grub-mkconfig can leak passwords

Package: grub-common Version: 1.99-12 Severity: normal The output configuration is created with this code. if test x${grub_cfg} != x; then rm -f ${grub_cfg}.new exec ${grub_cfg}.new # Allow this to fail, since /boot/grub/ might need to be fatfs to support some # firmware

Bug#651245: dnssec-tools: NSEC checking is completely broken

Package: dnssec-tools Version: 1.11-1 Severity: normal Tags: patch The ordering function is broken in two ways. * Firstly, there's a typo: it compares two labels from the same name, rather than the two different names. * Secondly, there's a more subtle bug when one of the names is a

Bug#650814: syslog-ng-core: missing module `afsql' in default module list

Package: syslog-ng-core Version: 3.3.1.dfsg-1 Severity: minor The `debian/rules' file sets an explicit default-modules list override_dh_auto_configure: SOURCE_REVISION=$(shell dpkg-parsechangelog | sed -n /^Version:/s/^Version: /$(shell lsb_release -is)\//p) \ dh_auto_configure

Bug#646122: lvm2: Snapshot removal fails partway, then succeeds leaving devicemapper debris

I'm not enjoying the lvm source code much. There's obviously some kind of race going on: if I stop for a short while at breakpoints at the two `lv_resume' calls in `vg_remove_snapshot' (lines 218 and 222 of lib/metadata/snapshot_manip.c) then everything works OK. If I downgrade to 2.02.66-5

Bug#646122: lvm2: Snapshot removal fails partway, then succeeds leaving devicemapper debris

Package: lvm2 Version: 2.02.88-1 Severity: normal In the transcript below: * I create a snapshot (of an idle volume, not mounted); * I inspect the devmapper mappings; * I try to remove the snapshot, but LVM fails partway and can't put the pieces back together. * Try again: this

Bug#643606: ssh-keygen: `-V' relative end-times -- implementation doesn't match manpage

Package: openssh-client Version: 1:5.8p1-7 Severity: minor The manpage ssh-keygen.1 has this to say about the `-V' option. -V validity_interval Specify a validity interval when signing a certificate. A validity interval may consist of a single time, indicating

Bug#633932: dump: Related bugs

I've seen this bug too. It's caused by a binary- and source- incompatible change in e2fslibs, which I reported as #636418. This is also responsible for the FTBFS #634421. This is, of course, extremely bad form of e2fslibs, which should have changed the soname and package name. -- [mdw] --

Bug#636418: e2fslibs: New version breaks dump (source and binary)

Package: e2fslibs Version: 1.42~WIP-2011-07-02-1 Severity: important With this version of e2fslibs, dump 0.4b44-1 is a total loss: it fails with SIGFPE during pass IV. An example run: [ponder ~]r dump -0v -f/dev/null /dev/vg-ponder/db DUMP: Date of this level 0 dump: Tue Aug 2 23:51:11 2011

Bug#632695: iptables: Option parser no longer accepts `! --fragment'

Package: iptables Version: 1.4.11.1-2 Severity: normal What's wrong: [ibanez ~]sudo iptables -A OUTPUT ! --fragment -j LOG iptables v1.4.11.1: cannot have ! before -f Try `iptables -h' or 'iptables --help' for more information. (Simple `! -f' causes the same error report.) This is contrary to

Bug#630388: gnupg: `gpg --edit-key notexist' silently does nothing

Package: gnupg Version: 1.4.11-3 Severity: normal If you try to edit a key with an unrecognized id, GPG doesn't print anything other than its usual copyright banner, and exits zero. With `--no-greeting', it prints nothing at all. [ponder ~]gpg --no-greeting --edit-key notexist [ponder ~]echo

Bug#580791: python-gobject: glib.main_context_default() causes immediate segfault

Laurent Bigonville bi...@debian.org writes: Are you still experiencing this bug? Yes. I'm now using python-gobject 2.21.4+is.2.21.3-1, and: [metalzone /tmp/mdw]cat break.py import glib print glib.main_context_default() [metalzone /tmp/mdw]python2.5 break.py Segmentation fault [metalzone

Bug#580791: python-gobject: glib.main_context_default() causes immediate segfault

Laurent Bigonville bi...@debian.org writes: Could you please also try with the version in experimental? That doesn't help either. Do I take it that you can't reproduce the problem? It's not just (all four of) my systems which exhibit it; everyone else I've asked to run python -e

Bug#580791: python-gobject: glib.main_context_default() causes immediate segfault

m...@distorted.org.uk (Mark Wooding) writes: python -e 'import glib; print glib.main_context_default()' Sorry. I meant python -c 'import ...'. -- [mdw] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas

Bug#604878: iodine: Uninitialized variable prevents forwarding from working properly

Package: iodine Version: 0.6.0~rc1-2 Severity: normal Tags: patch I use iodine with forwarding (my network configuration is a NAT disaster, but that's not important). Recently I was notified that my outward-facing DNS wasn't working. Upon investination, I discovered that iodine had stopped

Bug#585931: gstreamer0.10-plugins-good: vorbisenc forces mono if channel positions specified on stereo stream

Package: gstreamer0.10-plugins-good Version: 0.10.22-1 Severity: minor If an element upstream of vorbisenc offers a stereo audio stream with channel-position specifiers in its caps, then vorbisenc seems to refuse this, and the stream downgrades to mono. This is particularly apparent when you're

Bug#583093: restore -P creates useless index for compressed dumps

Package: dump Version: 0.4b41-6 Severity: normal Tags: patch To reproduce: make a compressed dump of a filesystem: # dump -0 -fdump -z /var [...] Now generate a QFA index: $ restore -Pqfa -fdump -v -a Verify tape and initialize maps Input is from a

Bug#581624: pulseaudio: Stuttering playback from Wine

Package: pulseaudio Version: 0.9.21-1 Severity: normal I listen to music using Spotify running under Wine. Every now and then -- I don't know exactly how to provoke it, but leaving the machine idle for a few hours is usually good enough -- the audio output of Spotify is unlistenably choppy, and

Bug#580791: python-gobject: glib.main_context_default() causes immediate segfault

Package: python-gobject Version: 2.21.1-1 Severity: normal [crybaby /tmp/mdw]cat break.py import glib print glib.main_context_default() [crybaby /tmp/mdw]python break.py Segmentation fault What's going on? glib/pyglib.c seems to be somewhat confused about how it's getting hold of its type

Bug#576223: dictionaries-common: ispell process current directory prevents unmounting removable media

Agustin Martin agustin.mar...@hispalinux.es writes: I have to think about this more carefully, but using the directory where ispell is called as a directory that can contain personal dictionaries in parallel with the possible standard personal dictionary is usual ispell behavior when no

Bug#576223: dictionaries-common: ispell process current directory prevents unmounting removable media

Package: dictionaries-common Version: 1.5.1 Severity: normal Emacs launches an ispell process (by which I mean whatever you configured via `ispell-program-name') spontaneously, if you turn on `flyspell-mode' (e.g., through a mode hook) or by using C-$ (M-x ispell-word) and friends interactively.

Bug#477169: post-sysdef-install.lisp: GET-UID broken on ECL and otherwise inconsistent

Package: common-lisp-controller Version: 6.12 Severity: important Tags: patch I recently found that my ECL fails to ASDF-whatever systems. It fails like this: [metalzone ~]ecl ;;; Loading #P/usr/lib/ecl/cmp.fas ;;; Loading #P/usr/lib/ecl/sysfun.lsp ECL (Embeddable Common-Lisp) 0.9i Copyright

Bug#473856: emacs22-common-non-dfsg: Would be nice to provide printable docs (PS or PDF)

Package: emacs22-common-non-dfsg Version: 22.1+1-1 Severity: wishlist The Emacs texinfo manuals all seem to turn into reasonable DVI (and thence to PostScript), and most turn into PDF when nudged gently by texi2pdf. It'd be kinda cool to package these more attractive documents. Really not a

Bug#471844: python-codespeak-lib: Installation trashes itself when greenlets imported as root

Package: python-codespeak-lib Version: 0.9.0-4 Severity: important Running as me: $ python -c 'from py.magic import greenlet' $ [no problem] Running as root: # python -c 'from py.magic import greenlet' Traceback (most recent call last): File string, line 1, in ? File

Bug#434230: libthunar-vfs-1-2: Can't build-rename with regexps: Build-Depend on libpcre3-dev?

Package: libthunar-vfs-1-2 Version: 0.8.0-5 Severity: normal Regular expression search/replace isn't available in the bulk-rename dialogue because thunar wasn't built against libpcre. I've rebuilt my package (which is why libpcre3 appears in the list below). -- System Information: Debian

Bug#433802: cl-swank: Slime crashes CMUCL on disconnect

Package: cl-swank Version: 1:20070409-3 Severity: normal Tags: patch To demonstrate: * Start cmucl in a window. * Say to Lisp: (load /usr/share/common-lisp/source/slime/swank-loader.lisp) * Say to Lisp `(create-server)'. * Start Emacs. * Say to Emacs `M-x slime-connect RET RET

Bug#433814: cl-uffi: Silently fails to load non-existent .so files

Package: cl-uffi Version: 1.5.18-2 Severity: normal Tags: patch On CMUCL, the uffi:load-foreign-library function attempts to use sys::load-object-file to load .so files (rather than falling back to alien:load-foreign as it does for other types). However, unlike alien:load-foreign,

Bug#433814: Acknowledgement (cl-uffi: Silently fails to load non-existent .so files)

Nnng, sorry. I botched the tabs in the patch. Here's one that ought to work. --- libraries.lisp~ 2007-07-19 18:53:49.0 +0100 +++ libraries.lisp 2007-07-19 18:57:14.0 +0100 @@ -96,7 +96,9 @@ #+cmu (let ((type (pathname-type (parse-namestring filename

Bug#432000: wireshark-dev: required headers still missing

Package: wireshark-dev Version: 0.99.6pre1-1 Followup-For: Bug #432000 The following headers (at least!) are still missing from this package: epan/ftypes/*.h epan/dfilter/*.h register.h I'd second the OP's request for an automated test before release. My configure fragment caught these, so

Bug#432000: wireshark-dev: required headers still missing

Michael Koch [EMAIL PROTECTED] wrote: This mail was surely meant to be a followup for #423000, and not #432000. D'oh! Typo. Sorry. -- [mdw] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#430833: libasound2: PCM plugin `lfloat' not built

Package: libasound2 Version: 1.0.14a-1 Severity: normal Tags: patch The PCM plugin `lfloat' isn't compiled into libasound. In particular, this prevents the `plug' plugin from doing linear-float conversion, and in turn this means that hardly any ALSA clients can use the JACK plugin from

Bug#411140: pari-gp: Package doesn't contain pari.el

Package: pari-gp Version: 2.3.1-2 Severity: minor Tags: patch The pari-gp package includes a collection of Emacs macros in /usr/share/doc/pari-gp/examples. However, it omits the rather important pari.el file, without which the rest are rather useless. The reason for this seems to be

Bug#408633: gthumb: Fullscreen mode doesn't honour keep-previous-zoom preference

Package: gthumb Version: 3:2.8.0-1 Severity: normal Tags: patch Find a directory of images smaller than the screen. Set preference `Viewer - After loading an Image' to `Keep previous zoom'. Enter fullscreen mode by pressing `f'. Make image zoom to fit by pressing `x'. Step to next image by

Bug#362011: libpcre3-dev: Missing manpage pcrepartial.3

Package: libpcre3-dev Version: 6.4-1.1 Severity: normal Tags: patch The manual pages pcre(3) and pcreapi(3) have cross-references to pcrepartial(3), but that manpage isn't shipped. This is actually a bug in the upstream Makefile. The following patch fixes it. Makefile.in |1 + 1 files

Bug#358589: calc: Still simplifies ln(-2) wrongly

Package: calc Version: 2.02f-26 Severity: normal Tags: patch I would reopen bug #35910, but the bug system's forgotten it ever existed. But the bug still isn't fixed, despite a claim that it was in 1999. To demonstrate: * Start a fresh Emacs, * `M-# M-#' * `m s' * `2 n RET' * `L' *

Bug#330161: Proxy patch

This doesn't do proxy authentication or anything similarly fancy, but it does actually make logjam work well enough for me. (Against 4.5.1-4.) --- src/network-soup.c~ 2005-08-24 09:14:27.0 +0100 +++ src/network-soup.c 2005-12-20 15:12:45.0 + @@ -51,7 +51,7 @@ GString