Bug#779892: hexchat: Connecting to a server via /server command causes crash
The bug is debian-specific and caused by missing braces around an if
block. The attached patch fixes it.
Lauri
--- hexchat-2.10.1/src/fe-gtk/joind.c~ 2015-08-21 10:19:01.0 +0300
+++ hexchat-2.10.1/src/fe-gtk/joind.c 2015-08-21 11:10:16.547254921 +0300
@@ -245,20 +245,22 @@
G_CALLBACK (joind_radio2_cb), serv);
g_signal_connect (G_OBJECT (okbutton1), clicked,
G_CALLBACK (joind_ok_cb), serv);
if (serv-network)
+ {
if (g_ascii_strcasecmp(((ircnet*)serv-network)-name, OFTC) == 0)
{
gtk_entry_set_text (GTK_ENTRY (entry1), #debian);
gtk_toggle_button_set_active (GTK_TOGGLE_BUTTON(radiobutton2), TRUE);
}
if (g_ascii_strcasecmp(((ircnet*)serv-network)-name, freenode) == 0)
{
gtk_entry_set_text (GTK_ENTRY (entry1), #debian);
gtk_toggle_button_set_active (GTK_TOGGLE_BUTTON(radiobutton2), TRUE);
}
+ }
gtk_widget_grab_focus (okbutton1);
gtk_widget_show_all (dialog1);
}
Bug#657856: mlocate: may leak sensitive information
Subject: mlocate: may leak sensitive information Package: mlocate Version: 0.22.2-1 Severity: normal By default, updatedb.mlocate traverses users' home directories. In a setup where home directories (and swap) are encrypted, but for performance reasons the rest of the system isn't, this means that if updatedb.mlocate is run while a user is logged in and her home directory is mounted, then the names of the files under the encrypted home are stored unencrypted under /var/lib/mlocate, which makes them more vulnerable if the hardware gets compromised. This is easy to fix, of course, but it is a very, very non-obvious pitfall for someone trying to build a secure system, especially as mlocate seems to be the default for Debian (I don't recall installing it explicitly). It would be more prudent to not sniff around private home directories by default. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-0.bpo.1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages mlocate depends on: ii adduser 3.112 add and remove users and groups ii libc6 2.13-21Embedded GNU C Library: Shared lib mlocate recommends no packages. mlocate 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#633799: Info received (Bug#633799: Acknowledgement (getmail4: Mboxrd format is not supported))
Just an update to confirm that this bug is still present in 4.20.4. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#633799: [l...@iki.fi: Bug#633735: getmail4: From_-escaping isn't done within multipart messages]
(Charles added to To-list since the getmail list is subscriber-only and there is no obvious way to get a post-only subscription.) Okay. So the actual problem here is that the original message contains the invalid content, and getmail's straight-paper-path tried very hard to preserve the original content as-is (i.e. don't rewrite messages Just Because). No, the original message is quite valid. Its content may not be what the sender intended, but it is quite legal for the body of an email message to contain arbitrary text, including lines beginning with From . If getmail produces an ill-formed mbox from well-formed input, the fault lies with getmail. The messages received from the IMAP server _need_ to be rewritten, for a very good reason: the mbox format requires it. You can't just concatenate mail messages into a file verbatim and call it a mbox. Even until now, From_-lines within the body of the message were -escaped, but due to a bug in Python's email library, this didn't happen for multipart messages. If you are unwilling to fix the issue in getmail, I can just report it to the Python maintainers and once the email library works correctly, getmail users will eventually (years from now) reap the benefits. Even then, the python library produces mboxo instead of mboxrd, and getmail's documentation should reflect this, unless real mboxrd support is added. Lauri Alanko acknowledges that he had an IMAP problem for his environment in another bug report. That was a _different_ environment, not related to the current issue. And although that environment did in fact have a problem, the problem was reverse: it served contents of messages with From_-lines escaped, although the IMAP server should decode any escapings its internal storage format happens to use before sending the content. This is the crux of the problem, and the reason why imap-mbox -interaction isn't so straightforward: messages in a mbox file _must_ be From_-escaped. Messages transmitted through IMAP _must not_ be From_-escaped. Lauri -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#633735: getmail4: From_-escaping isn't done within multipart messages
Package: getmail4 Version: 4.20.0-1 Severity: important Attached is a file that getmail's mboxrd backend produced after fetching a single message from an IMAP server. Note that in the middle of the file there is a From_-line (presumably produced by a mishap of the sender) that isn't escaped. Since there's no Content-Length either, every tool interprets the file as a mailbox containing two messages. I have located the problem. In getmailcore.message.Message.__init__, an email.Parser.HeaderParser is used to parse the incoming message. The headerparser leaves the payload as an uninterpreted string even for multipart messages. In email.generator.Generator._handle_multipart, uninterpreted payloads are written out verbatim without the From_-mangling. This is possibly a bug in Python core. I have tested both switching the parser to email.Parser.Parser, and fixing the From_-mangling in the email library, and either alone seems to fix the problem. -- System Information: Debian Release: squeeze/sid APT prefers stable APT policy: (900, 'stable'), (2, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages getmail4 depends on: ii python 2.6.6-3+squeeze6 interactive high-level object-orie ii python-support 1.0.8automated rebuilding support for P getmail4 recommends no packages. getmail4 suggests no packages. -- no debconf information example.mboxrd.gz Description: GNU Zip compressed data
Bug#633735: getmail4: From_-escaping isn't done within multipart messages
On Wed, Jul 13, 2011 at 09:12:24PM +0900, Osamu Aoki wrote: Have you tried the latest version in unstable? Yes, I used 4.20.3 to check how to fix the problem, and it didn't work before I fixed it. I hadn't installed 4.20.3 globally, so the system information showed the older version, sorry. Lauri -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#633780: getmail4: EOL-conversion leaves invalid Content-Length
Package: getmail4 Version: 4.20.0-1 Severity: normal I have a setup where the IMAP server is backed by a mbox file, which has also been accessed directly by mutt. Mutt has added Content-Length headers to the messages in the mbox. The IMAP server is not aware of these and serves them as normal headers. Some of the messages in the file have CRLF-terminated lines. When getmail fetches these messages, it converts the CRLFs to LFs. However, it leaves the Content-Length header untouched, even though this header now has an invalid value since the CRLF-LF conversion changed the length of the message body. Invalid Content-Lengths are dangerous, especially if they are too large. Many tools (e.g. mutt, dovecot's mbox backend, formail in default mode) trust the Content-Length if it is present, but if they don't find a message boundary (From_-line) where the Content-Length indicates, the scan _forward_ until they find a From_-line. The end result is that the following message gets merged with the one that had the invalid Content-Length. Of course getmail doesn't claim to support the mboxcl format, but it should not produce files that pretend to support it by having the Content-Length header. Hence, getmail should either remove the header, or alternatively support mboxcl properly by recalculating it to a correct value. -- System Information: Debian Release: squeeze/sid APT prefers stable APT policy: (900, 'stable'), (2, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages getmail4 depends on: ii python 2.6.6-3+squeeze6 interactive high-level object-orie ii python-support 1.0.8automated rebuilding support for P getmail4 recommends no packages. getmail4 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#633799: getmail4: Mboxrd format is not supported
Package: getmail4 Version: 4.20.3-2 Severity: normal Although getmail has a destination named Mboxrd, and although the documentation explicitly says that it produces mboxrd-format files, this does not in fact seem to be the case. The Mboxrd destination produces mboxo files. For instance, I had the following test file being served by dovecot. Dovecot's mbox backend uses mboxcl2, i.e. it relies only on the Content-Length header to delimit messages, and leaves the body of the message unescaped. |From l...@iki.fi Wed Jul 13 22:04:07 2011 |From: me |To: whoever |Content-Length: 80 | |This is some text. |From 0 |From 1 |From 2 |From 3 |Some more text at the end. | (I prepended | to the lines to prevent further mangling while the bug report is in transit.) The file produced by getmail's Mboxrd destination looks like the following: |From unknown Wed Jul 13 23:12:36 2011 |Return-Path: unknown |Delivered-To: unknown |Received: from localhost (127.0.0.1:993) by bq.la.iki.fi with IMAP4-SSL; 13 | Jul 2011 20:12:36 - |From: me |To: whoever | |This is some text. |From 0 |From 1 |From 2 |From 3 |Some more text at the end. | Note that only the line From 0 has been escaped, not any of the lines following it. This format is mboxo, not mboxrd. As is obvious, mboxo is not a very good format since from the fetched mail we cannot reconstruct the original message accurately, as the distinction between From 0 and From 1 has been lost. This is arguably a documentation bug, but a severe one, as the documentation explicitly gives the wrong information several times, and assuming the wrong mbox format can cause corruption of the messages. -- System Information: Debian Release: squeeze/sid APT prefers stable APT policy: (900, 'stable'), (2, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages getmail4 depends on: ii python 2.6.6-3+squeeze6 interactive high-level object-orie ii python-support 1.0.8automated rebuilding support for P getmail4 recommends no packages. getmail4 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#633780: Acknowledgement (getmail4: EOL-conversion leaves invalid Content-Length)
Sorry, this was an erroneous report. The IMAP server had not served Content-Length headers, and they had ended up in my files for reasons unrelated to getmail. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#633799: Acknowledgement (getmail4: Mboxrd format is not supported)
Attached is a patch that should fix all the problems I've reported. It
bypasses the Python email library's mboxo-escaping and does
mboxrd-escaping manually. This is also applied to multipart messages,
so it also fixes #633735. Although #633780 turned out to be a
non-issue, I left the line that deletes the Content-Length -field. It
doesn't hurt to make sure.
diff -ur getmail4-4.20.3/getmailcore/message.py
getmail4-4.20.3.new/getmailcore/message.py
--- getmail4-4.20.3/getmailcore/message.py 2011-07-14 00:32:06.0
+0300
+++ getmail4-4.20.3.new/getmailcore/message.py 2011-07-14 00:48:32.503572633
+0300
@@ -9,6 +9,7 @@
import os
import time
import cStringIO
+import re
import email
import email.Errors
import email.Utils
@@ -28,6 +29,9 @@
'recipient'
)
+# Lines that should be escaped in mboxrd mailboxes
+from_re = re.compile(^(*From ), re.MULTILINE)
+
###
def corrupt_message(why, fromlines=None, fromstring=None):
log = getmailcore.logging.Logger()
@@ -151,7 +155,18 @@
content += '; ' + time.strftime('%d %b %Y %H:%M:%S -',
time.gmtime())
f.write(format_header('Received', content))
-gen = Generator(f, mangle_from, 0)
+# Since we reformat the message with escaping and EOL
+# conversion, Content-Length is probably no longer accurate. The
+# header isn't needed for mboxrd anyway.
+del self.__msg['Content-Length']
+# We escape the payload by ourselves, since the generator would
+# produce mboxo.
+gen = Generator(f, False, 0)
+if mangle_from:
+payload = self.__msg.get_payload()
+# The payload is always a string since it is produced by
+# HeaderParser.
+self.__msg.set_payload(from_re.sub(\\1, payload))
# From_ handled above, always tell the generator not to include it
try:
gen.flatten(self.__msg, False)
Bug#354358: libswt-gtk-3.1-java: Unusable on amd64 (ia32-specific sources used)
May I ask what exactly is preventing this bug from being fixed? As I told two months ago, it seems that the problem is only that upstream's 64-bit sources aren't used by the package on amd64. When I applied the changes between the 32-bit and 64-bit upstream sources to the build tree, everything worked, and has worked now for two months. The only problem is the window closing in azureus 2.4.0.2, but I suspect that is not related to SWT. I see this bug has been tagged upstream, but the upstream sources are just fine, they are just used wrong by the debian package. So what is preventing from including the 64-bit parts in the debian package and closing the bug? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364706: azureus: Also unable to close the warning window
Package: azureus Version: 2.4.0.2-1 Followup-For: Bug #364706 Just another data point here. After upgrading to 2.4.0.2, the warning window wouldn't close if I click hide. My window manager is ion3, and I'm using a patched version of libswt-gtk-3.1-java, since #354358 still hasn't been closed. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16la3 Locale: LANG=C, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Versions of packages azureus depends on: ii gij-4.0 [java-virtual-machine 4.0.3-2The GNU Java bytecode interpreter ii libcommons-cli-java 1.0-8 API for working with the command l ii liblog4j1.2-java 1.2.13-1 Logging library for java ii libseda-java 3.0-3 the Staged Event-Driven Architectu ii libswt-gtk-3.1-java 3.1.2-1Standard Widget Toolkit for GTK Ja ii sun-j2se [java2-runtime] 1.5.0-5Dummy for Sun J2SE Versions of packages azureus recommends: pn java-package none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354358: libswt-gtk-3.1-java: Unusable on amd64 (ia32-specific sources used)
On Thu, May 04, 2006 at 09:19:55AM -0600, Shaun Jackman wrote: For the intents of a Debian maintainer, upstream essentially does not release a source package of SWT *at all*, since it does not contain the necessary scripts to actually build the package. Ah, right. Essentially you're saying that with upstream's current release policy, maintaining a multiplatform package might require surprising amounts of work, and you don't want to take the risk that some future changes will make the maintainer's job a living hell. This is certainly a reasonable stance. However, I think you're overestimating the chances of this happening. Consider: the patch only contains type- and typecode-differences in _generated_ code. If you ever need to do debian-specific patches to generated code, you are screwed already, even if you only package for i386: a new upstream release might introduce changes in the generation process and then your patches wouldn't be usable any longer. So as long as you decide to package for _any_ architecture without having the true sources from upstream, adding further architectures isn't likely to add much to the risk. By the way, have you actually looked at the diff between src.zip contents in the linux-x86 and linux-x86_64 packages? The lines that differ only contain _interface_ specifications: types and names. Unless you plan on adding new functionality, you probably never need to touch these. Bug fixes would only affect actual code, and those parts are not touched by the diff. Incidentally, have you tried out if the x86_64 sources work on 32-bit x86? I don't see why they shouldn't, since the only difference is that the 64-bit sources store native pointers in longs instead of ints. It would yield a performance penalty on 32-bit, but it would allow you to support both x86 and x86_64 from the same sources. Of course, all this mess is Sun's fault. For some completely unfathomable reason, Java and JNI don't provide a primitive type for opaque native pointers, so everyone has to cast them into ints or longs... But thanks for the response. I certainly agree that Eclipse should provide their _real_ sources. Yet even if they don't, it's better to do what we can with what we have... Lauri -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#365621: kernel-package: Produced 2.6 image packages don't depend on module-init-tools
Package: kernel-package Version: 10.045 Severity: normal Here's the Depends field for a linux 2.6.16-5 image I built with make-kpkg: Depends: yaird (= 0.0.11-8) | initramfs-tools (= 0.53) | linux-initramfs-tool, coreutils | fileutils (= 4.0) Here's the Depends field for linux-image-2.6.16-1-amd64-k8: Depends: module-init-tools (= 0.9.13), e2fsprogs (= 1.35-7), initramfs-tools (= 0.53) | yaird (= 0.0.12-8) | linux-initramfs-tool I recently started using debfoster and removed all non-custom kernels. The result was that module-init-tools also got accidentally removed, which broke my system. I had to use a rescue disk to fix the system. I very much think that the packages produced by make-kpkg should depend on module-init-tools to prevent this kind of thing from happening. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16la3 Locale: LANG=C, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Versions of packages kernel-package depends on: ii dpkg 1.13.18package maintenance system for Deb ii dpkg-dev 1.13.18package building tools for Debian ii file 4.17-1 Determines file type using magic ii gcc [c-compiler] 4:4.0.3-3 The GNU C compiler ii gcc-3.4 [c-compiler] 3.4.6-1The GNU C compiler ii gcc-4.0 [c-compiler] 4.0.3-2The GNU C compiler ii gettext 0.14.5-2 GNU Internationalization utilities ii make 3.81-1 The GNU version of the make util ii perl 5.8.8-4Larry Wall's Practical Extraction ii po-debconf1.0manage translated Debconf template Versions of packages kernel-package recommends: ii bzip2 1.0.3-2high-quality block-sorting file co ii libc6-dev [libc-dev] 2.3.6-7GNU C Library: Development Librari -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#331286: quack-el: W3M dependency also superfluous
Package: quack-el Version: 0.28-1 Followup-For: Bug #331286 Both of quack-el's dependencies are broken: quack works just fine with emacs-snapshot and xemacs, so it should just depend on emacsen. Moreover, the w3m functionality in quack is not crucial (I have never used it), so w3m shouldn't be a hard dependency, but rather a recommendation or a suggestion. It's silly that installing a scheme mode for emacs also requires installing imagemagick, openssl and ca-certificates. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16la3 Locale: LANG=C, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Versions of packages quack-el depends on: ii emacs21 21.4a-3The GNU Emacs editor ii w3m-el1.4.4-1a simple Emacs interface of w3m quack-el recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361046: gjay: Crashes upon encounterin an mp3 free format frame
Package: gjay
Version: 0.2.8.3-4.1
Severity: normal
GJay segfaulted in the initial scanning phase upon reading a particular
mp3 file.
#0 0x0041b2a1 in header_bitrate (h=0x7fe89040) at mp3.c:300
#1 0x0041b1f6 in frame_length (header=0x7fe89040) at mp3.c:291
#2 0x0041b184 in get_header (file=0xa38f60, header=0x7fe89040)
at mp3.c:287
#3 0x0041ad62 in get_first_header (mp3=0x7fe892b0,
startpos=3240540) at mp3.c:204
#4 0x0041a90f in get_mp3_info (mp3=0x7fe892b0, scantype=1,
fullscan_vbr=0) at mp3.c:132
It turns out that the problem is that at
int header_bitrate(mp3header *h) {
return bitrate[h-version 1][3-h-layer][h-bitrate-1];
}
h-bitrate had the value of 0, causing an array underrun. According to
quick googling, zero is a valid value for the bitrate field in a frame
header, indicating a free format frame. I don't know exactly what this
means, and it may well be that the mp3 file was more or less broken.
In any case, value zero in the bitrate field should be either support or
detected and rejected.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16la2
Locale: LANG=C, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
Versions of packages gjay depends on:
ii libatk1.0-0 1.10.3-1 The ATK accessibility toolkit
ii libc6 2.3.6-3 GNU C Library: Shared libraries an
ii libcairo2 1.0.2-3 The Cairo 2D vector graphics libra
ii libfontconfig1 2.3.2-2 generic font configuration library
ii libglib2.0-02.10.1-2 The GLib library of C routines
ii libgsl0 1.7.90-1 GNU Scientific Library (GSL) -- li
ii libgtk2.0-0 2.8.13-1 The GTK+ graphical user interface
ii libpango1.0-0 1.12.0-2 Layout and rendering of internatio
ii libx11-66.8.2.dfsg.1-11 X Window System protocol client li
ii libxcursor1 1.1.3-1 X cursor management library
ii libxext66.8.2.dfsg.1-11 X Window System miscellaneous exte
ii libxi6 6.8.2.dfsg.1-11 X Window System Input extension li
ii libxinerama16.8.2.dfsg.1-11 X Window System multi-head display
ii libxrandr2 6.8.2.dfsg.1-11 X Window System Resize, Rotate and
ii libxrender1 1:0.9.0.2-1 X Rendering Extension client libra
ii mp3info 0.8.4-8 An MP3 technical info viewer and I
ii mpg321 [mpg123] 0.2.10.3 A Free command-line mp3 player, co
ii xmms1.2.10+cvs20050809-5 Versatile X audio player
gjay recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361056: gjay: Analysis broken on AMD64
Package: gjay
Version: 0.2.8.3-4.1
Severity: important
Tags: patch
It turns out that on AMD64, gjay's analysis quietly just fails on every
file without anything being reported to the user. The reason is that the
parsing of the temporary wav file header is broken for the age-old
reason: unwarranted assumptions about the sizes of C types.
Attached is a simple patch that seems to fix things. However, the very
fact that the program has been written by someone who parses file
formats like this:
fread(wsfile.header, sizeof(waveheaderstruct), 1, f);
(i.e. making stupendously specific assumptions about the platform and
the compiler's struct representations)
means that the correct functioning of the entire program under 64-bit
platforms is suspect, and the code should probably be thoroughly
reviewed for any and all other platform-specific assumptions that get
broken under amd64.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16la2
Locale: LANG=C, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
Versions of packages gjay depends on:
ii libatk1.0-0 1.10.3-1 The ATK accessibility toolkit
ii libc6 2.3.6-3 GNU C Library: Shared libraries an
ii libcairo2 1.0.2-3 The Cairo 2D vector graphics libra
ii libfontconfig1 2.3.2-2 generic font configuration library
ii libglib2.0-02.10.1-2 The GLib library of C routines
ii libgsl0 1.7.90-1 GNU Scientific Library (GSL) -- li
ii libgtk2.0-0 2.8.13-1 The GTK+ graphical user interface
ii libpango1.0-0 1.12.0-2 Layout and rendering of internatio
ii libx11-66.8.2.dfsg.1-11 X Window System protocol client li
ii libxcursor1 1.1.3-1 X cursor management library
ii libxext66.8.2.dfsg.1-11 X Window System miscellaneous exte
ii libxi6 6.8.2.dfsg.1-11 X Window System Input extension li
ii libxinerama16.8.2.dfsg.1-11 X Window System multi-head display
ii libxrandr2 6.8.2.dfsg.1-11 X Window System Resize, Rotate and
ii libxrender1 1:0.9.0.2-1 X Rendering Extension client libra
ii mp3info 0.8.4-8 An MP3 technical info viewer and I
ii mpg321 [mpg123] 0.2.10.3 A Free command-line mp3 player, co
ii xmms1.2.10+cvs20050809-5 Versatile X audio player
gjay recommends no packages.
-- no debconf information
--- analysis.h.orig 2006-04-06 11:31:29.0 +0300
+++ analysis.h 2006-04-06 11:22:11.0 +0300
@@ -56,19 +56,19 @@
/* WAV file header */
typedef struct {
- char main_chunk[4]; /* 'RIFF' */
- unsigned long length; /* length of file */
- char chunk_type[4]; /* 'WAVE' */
- char sub_chunk[4]; /* 'fmt' */
- unsigned long length_chunk; /* length sub_chunk, always 16 bytes */
- unsigned short format; /* always 1 = PCM-Code */
- unsigned short modus; /* 1 = Mono, 2 = Stereo */
- unsigned long sample_fq; /* Sample Freq */
- unsigned long byte_p_sec; /* Data per sec */
- unsigned short byte_p_spl; /* Bytes per sample */
- unsigned short bit_p_spl; /* bits per sample, 8, 12, 16 */
- char data_chunk[4]; /* 'data' */
- unsigned long data_length; /* length of data */
+ gchar main_chunk[4]; /* 'RIFF' */
+ guint32 length; /* length of file */
+ gchar chunk_type[4]; /* 'WAVE' */
+ gchar sub_chunk[4]; /* 'fmt' */
+ guint32 length_chunk; /* length sub_chunk, always 16 bytes */
+ guint16 format; /* always 1 = PCM-Code */
+ guint16 modus; /* 1 = Mono, 2 = Stereo */
+ guint32 sample_fq; /* Sample Freq */
+ guint32 byte_p_sec; /* Data per sec */
+ guint16 byte_p_spl; /* Bytes per sample */
+ guint16 bit_p_spl; /* bits per sample, 8, 12, 16 */
+ gchar data_chunk[4]; /* 'data' */
+ guint32 data_length; /* length of data */
} waveheaderstruct;
/* Analysis.c */
Bug#361056: Acknowledgement (gjay: Analysis broken on AMD64)
There was also a buffer overrun in the frequency analysis code, which
caused very unpredictable results. Patch attached.
For explanation:
http://www.network-theory.co.uk/docs/gslref/gsl-ref_245.html
The terms for k=0 and k=N/2 are both purely real, and count as a
special case. Their real parts are stored in locations 0 and N/2
respectively, while their imaginary parts which are zero are not
stored.
The zero value did already have special treatment, but it was again used
in the loop as the value of j, causing ch1[window_size - j] to overrun.
--- analysis.c.orig 2006-04-06 12:54:28.0 +0300
+++ analysis.c 2006-04-06 12:42:03.0 +0300
@@ -618,8 +618,10 @@
gsl_fft_real_radix2_transform (ch1, 1, window_size);
mags [0] = fabs (ch1 [0]);
-
-for (j = 0; j window_size / 2; j++) {
+ if (mags [0] ch1max)
+ch1max = mags [j];
+
+for (j = 1; j window_size / 2; j++) {
mags [j] = sqrt (ch1 [j] * ch1 [j] + ch1 [window_size - j] * ch1
[window_size - j]);
if (mags [j] ch1max)
@@ -632,8 +634,10 @@
if (wsfile-header.modus == 2) {
mags [0] = fabs (ch2 [0]);
+ if (mags [0] ch2max)
+ ch2max = mags [j];
-for (j = 0; j window_size / 2; j++) {
+for (j = 1; j window_size / 2; j++) {
mags [j] = sqrt (ch2 [j] * ch2 [j] + ch2 [window_size - j] *
ch2 [window_size - j]);
if (mags [j] ch2max)
Bug#360076: tailor: Import fails when a CVS repo contains locks
Package: tailor
Version: 0.9.20-1
Severity: minor
I have a cvs repo that has in ancient past been manipulated with rcs
commands and there are some locks left on, so cvs rlog reports:
revision 1.48 locked by: la;
date: 1997-12-13 00:00:00 +; author: la; state: Exp; lines: +4 -1
Imported.
Note that there is a tab character between the version and the locked
by string. Now, when I try to run tailor to import this to darcs, it halts
with an error trace ending with:
File /usr/lib/python2.4/site-packages/vcpx/cvs.py, line 513, in
__updateState
state[e.name] = normalize_cvs_rev(e.new_revision)
File /usr/lib/python2.4/site-packages/vcpx/cvs.py, line 29, in
normalize_cvs_rev
r = [int(n) for n in rev.split('.')]
ValueError: invalid literal for int(): 48 locked
It turns out that in the function in question there is an attempt to
handle this case (cvs.py:25):
# handle locked files by taking only the first part of the
# revision string to handle gracefully lines like 1.1 locked
rev = rev.split(' ')[0]
However, the separator character doesn't match the tab so this fails.
Changing the ' ' to '\t' makes tailor work a bit further, but then it
dies with:
16:07:42 [I] /home/la/scratch/tmp/2006/03/30 $ cvs -d /home/la/today/cvsrepo -q
update -d -r 1.48\tlocked ani/ani0.txt
cvs [update aborted]: Numeric tag 1.48 locked contains characters other than
digits and '.'
So the revision parsing has failed at some other point, too.
It can be argued that the CVS repo is broken and tailor is not really
required to work in such situations, but since these kinds of repos
nevertheless do occur, it would be nice to see this fixed.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15-la5
Locale: LANG=C, LC_CTYPE=fi_FI.ISO-8859-1 (charmap=ISO-8859-1)
Versions of packages tailor depends on:
ii python2.4 2.4.2-2An interactive high-level object-o
tailor recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354358: libswt-gtk-3.1-java: Unusable on amd64 (ia32-specific sources used)
Package: libswt-gtk-3.1-java
Version: 3.1-3
Severity: grave
Justification: renders package unusable
Azureus hasn't been working on AMD64 Debian out of the box ever, I think.
This seems to be why.
From a Sun Hotspot 1.5.0_05 error log after a sigsegv when starting
Azureus:
Stack: [0x7f963000,0x7fb63000), sp=0x7fb5ead8, free
space=2030k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [libc.so.6+0x74ac6]
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j org.eclipse.swt.internal.gtk.OS.memmove([BII)V+0
j org.eclipse.swt.internal.Converter.wcsToMbcs(Ljava/lang/String;[CZ)[B+60
Then, from the sources for swt-gtk-3.1.2 (in os.c):
JNIEXPORT void JNICALL OS_NATIVE(memmove___3BII)
(JNIEnv *env, jclass that, jbyteArray arg0, jint arg1, jint arg2)
{
/* .. */
memmove((void *)lparg0, (const void *)arg1, (size_t)arg2);
/* .. */
}
Obviously treating a 32-bit jint like a 64-bit pointer cannot work.
It seems that when building the debian package, the same sources are
being used for both 32-bit and 64-bit architectures although the sources
are arch-specific:
http://dev.eclipse.org/mhonarc/lists/platform-swt-dev/msg04684.html
Indeed, the os.c in swt-3.1.2-gtk-linux-x86_64.zip (from eclipse.org)
contains a different version that uses jlongs instead of jints.
This is essentially the same problem as in bug #324030, of course. It's
claimed to be fixed, but all I see in xpcom.cpp is a casting hack to get
rid of compiler errors, but the precision loss is still there. On a
64-bit platform you _can't_ store a pointer in a jint, it just won't fit
no matter what you do. You have to use jlongs and make sure the java
code calling the native method also uses longs to store pointers. Having
a separate version that uses ints on 32-bit platforms seems like a
dubious performance hack.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-1-amd64-k8-smp
Locale: LANG=C, LC_CTYPE=fi_FI.ISO-8859-1 (charmap=ISO-8859-1)
Versions of packages libswt-gtk-3.1-java depends on:
ii libswt-gtk-3.1-jni3.1-3 Standard Widget Toolkit for GTK JN
libswt-gtk-3.1-java recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353610: skkserv: Segfault on amd64
Package: skkserv Version: 10.62a-7 Severity: grave Justification: renders package unusable This speaks for itself: la:~# /usr/sbin/skkserv Segmentation fault Cursory examination of the source for skkserv reveals that, not to put too fine a point on it, the code is a crock of shit: it doesn't include any of the necessary headers and it uses wrong types when calling library functions. Including the headers and running with gcc -Wall reveals a huge load of warnings. Apparently the code has been tuned to work only in an environment where ints, longs and pointers are exactly of the same size and are passed the same way, and this of course is not true on AMD64. Adding the missing headers at least makes it run without segfaulting, but the code is written so unportably (and in pre-ANSI style despite the copyrights being from 1994), that it really should be thoroughly reviewed and maybe rewritten before using on exotic (i.e. 64-bit) systems. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-amd64-k8-smp Locale: LANG=C, LC_CTYPE=fi_FI.ISO-8859-1 (charmap=ISO-8859-1) Versions of packages skkserv depends on: ii libc6 2.3.5-11 GNU C Library: Shared libraries an ii skkdic20051117-1 SKK Dictionary (SKK-JISYO.L) skkserv recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#350153: mimetex: Documentation not included in package
Package: mimetex Version: 1.50-1 Severity: minor The mimetex package includes in /usr/share/doc/mimetex/ only the README, which is an installation guide. The actual user manual, mimetex.html, is not packaged. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-amd64-k8-smp Locale: LANG=C, LC_CTYPE=fi_FI.ISO-8859-1 (charmap=ISO-8859-1) Versions of packages mimetex depends on: ii libc6 2.3.5-11 GNU C Library: Shared libraries an mimetex recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
