aintainers 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 acknowl
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
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 tha
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_C
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 h
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-
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 wor
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.
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 t
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 in
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: [0x7f96
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:
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 0x
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
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. The
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 pol
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
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.
La
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 head
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
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...@list
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 dele
22 matches
Mail list logo
