Package: openssh-server
Version: 1:5.3p1-3
Severity: important
Tags: patch
sshd is configured for /usr/bin/X11/xauth instead of
/usr/bin/xauth which is where it's installed. As a result X forwarding fails:
$ ssh - -X ttd 'echo x11 DISPLAY=$DISPLAY' 21 | grep -E 'x11|xauth'
debug2:
What are use-cases for current cat behaviour? If there is
none besides being used as a filter, let's please make it
ignore interactive viewers and just pipe the result to
stdout.
That makes sense, but I can think of no generic way to know if it's an
interactive viewer.
I thought
Brian, I appreciate your maintainership of run-mailcap, but first
you take a long time to reply then you upload immediately without
waiting for feedback on your comments. You have a couple people
here interested in testing and providing feedback prior to
release...
Brian White wrote: [Thu Dec 03
Brian White wrote: [Thu Dec 03 2009, 04:07:10PM EST]
I thought copiousoutput meant non-interactive stdout. Am
I mistaken?
copiousoutput indicates that the program produces a lot
of output and should be fed into a pager program so as to
not overwhelm the user. I've added
Package: expect-dev
Version: 5.43.0-19
Severity: minor
Without provocation, /usr/bin/expect_multixterm prints hello on
stdout. My psychiatrist tells me I need to stop talking to my
computer, so expect_multixterm is putting me in an awkward
situation by greeting me when I am not supposed to
Kirill Smelkov wrote: [Mon Oct 12 2009, 09:40:11AM EDT]
I too think, --action=cat should ignore X viewers.
After all, original --action=cat use case (as requested by me btw in
#526690) was to use it as canonical filter. So _filtering_ functionality
was assumed by --action=cat, and otherwise
Neither of these options should even disallow a rule. Instead,
a new terminal will be created or the output will be passed to
a pager.
If $DISPLAY isn't set, then a terminal can't be created. In that
case, tests will run pointlessly.
Additional cases apply for bug 533723.
It seems like
Whoops, forgot to attach it. Here it is.
#! /usr/bin/perl
###
#
# Run-Mailcap: Run a program specified in the mailcap file based on a mime
# type.
#
# Written by Brian White bcwh...@pobox.com
# This file has been
Ping? The bug described in this report is severe and the provided
patch fixes it correctly. Could the maintainer please apply the
patch? Thanks...
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
I'm seeing this same bug. It appears when the process is
connected to a pipe on stdout. Here is my simple test:
$ time -15 4 true
real0m0.013s
$ time -15 4 true | cat
real0m4.012s
The problem is that 02-seconds.patch forks a new process which
interferes with signal delivery. The
Package: createrepo
Version: 0.4.11-1
Severity: grave
Justification: renders package unusable
$ createrepo .
Traceback (most recent call last):
File /usr/share/createrepo/genpkgmetadata.py, line 26, in module
import rpm
File /usr/lib/python2.5/site-packages/rpm/__init__.py, line 7, in
I don't agree. Cat is like view but without a pager. To have it
choose otherwise would be confusing. The mailcap system is pretty
fragile in general; I don't think you should try to shoe-horn extra
functionality this way. Instead, create a filter action in the
rules you want and use
Package: mime-support
Version: 3.46-1
Severity: wishlist
It's not uncommon for mailcap to call run-mailcap if a document
needs multiple stages of conversion. However presently only the
first invocation gets --debug. This can be fixed with a minor
patch which I'll send in a minute.
-- System
diff -r e6fd9cda9d54 -r 9e53becd92ce run-mailcap
--- a/run-mailcap Fri Jun 19 20:21:58 2009 -0400
+++ b/run-mailcap Fri Jun 19 20:24:03 2009 -0400
@@ -10,7 +10,7 @@
###
-$debug=0;
Package: mime-support
Version: 3.46-1
Severity: normal
Presently run-mailcap will run mailcap test commands even
though the rule will eventually be discarded because of
needsterminal or copiousoutput flags.
I'll follow up with a patch that fixes the problem by moving the
block of code. (There
Package: mime-support
Version: 3.46-1
Severity: normal
I've observed that there's no way to differentiate between
calling run-mailcap to view an file (for example running ooffice)
and calling run-mailcap to translate a file to text/plain (for
example for viewing in mutt). The only indicator
diff -r 9e53becd92ce -r fe8091ee9501 run-mailcap
--- a/run-mailcap Fri Jun 19 20:24:03 2009 -0400
+++ b/run-mailcap Fri Jun 19 20:29:17 2009 -0400
@@ -438,6 +438,18 @@
($comm) = ($match =~ m/\Q$action\E=(.*?)\s*($|;)/);
}
next if (!$comm || $comm =~
diff -r fe8091ee9501 -r a1063b2fce1d run-mailcap
--- a/run-mailcap Fri Jun 19 20:29:17 2009 -0400
+++ b/run-mailcap Fri Jun 19 20:37:20 2009 -0400
@@ -439,7 +439,20 @@
}
next if (!$comm || $comm =~ m!(^|/)false$!i);
-if ($action ne 'print' $match =~
Note the patch above should be applied after the patch in
bug 533722. I thought moving the code first would make more
sense. Let me know if this is a problem.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
Could you please apply this patch?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
see http://www.zytor.com/pipermail/klibc/2009-April/002406.html
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Package: mime-support
Version: 3.44-1
Severity: normal
File: /usr/bin/run-mailcap
If there's a copiousoutput entry in mailcap for text/plain,
run-mailcap will pipe infinitely to new invocations of itself.
Here's a patch to fix it:
--- /usr/bin/run-mailcap2009-03-30 23:59:13.0
Package: libengine-pkcs11-openssl
Version: 0.1.4-1
Severity: grave
Justification: renders package unusable
See http://www.opensc-project.org/engine_pkcs11/ticket/11
I reported this bug upstream over a year ago and it was finally
fixed. Can we pull this patch in to Debian ASAP? It's a huge
pain
This bug and #488754 are both simple bugs with patches attached.
What's holding them up?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Package: pulseaudio
Version: 0.9.10-2
Severity: normal
/etc/init.d/pulseaudio reports the wrong status for start. $? is
referenced after code following start-stop-daemon. Most of the
time it will be zero regardless of whether or not the daemon
starts.
The following patch solves the problem:
Package: pulseaudio
Version: 0.9.10-2
Severity: normal
Sometimes pulseaudio takes a second to stop. This can cause
restart to fail:
$ sudo /etc/init.d/pulseaudio restart
Stopping PulseAudio Daemon.
Starting PulseAudio Daemon/usr/bin/pulseaudio already running.
This can be fixed by using the
Bram has fixed this now upstream:
ftp://ftp.vim.org/pub/vim/patches/7.1/7.1.125
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Package: vim-full
Version: 1:7.1-022+1
Severity: minor
--- Please enter the report below this line. ---
In a terminal, v:termresponse is set to the response to the t_RV
escape code. The TermResponse autocmd fires when v:termresponse is
set. This works normally in xterm and gnome-terminal at
Steinar H. Gunderson wrote: [Sun Aug 05 2007, 02:35:48PM EDT]
This is interesting -- I got home to my testing machine, and
I managed to reproduce it -- but only once. When I restarted
nfs-kernel-server (via the init.d script), the hanging processes
resumed, and from there it was completely
Michelle Konzack wrote: [Fri Aug 03 2007, 07:57:36AM EDT]
Which can not work, since /proc must be the /proc of the machine WHICH
is mounting the nfs-share.
Your statements represent a misreading of the bug. Let's take
a step-by-step approach:
1. The server has /etc/exports:
/foo
Package: nfs-kernel-server
Version: 1:1.1.0-11
Severity: serious
--- Please enter the report below this line. ---
When a client attempts to read a bind-mounted proc directory from the
server, the server never responds. Found this with wireshark and
narrowed down to a simple test. Other
Steinar H. Gunderson wrote: [Sat Jul 28 2007, 08:45:47PM EDT]
In any case, the severity massively inflated -- I assume you meant
grave and not serious,
Regarding this part, the NFS server freezing in a situation when it
previously worked is surely a serious error. And I think that the
Steinar H. Gunderson wrote: [Sat Jul 28 2007, 08:45:47PM EDT]
Uhm, why do you want to export your /proc? I'm unsure if that's supported at
all. In any case, the severity massively inflated -- I assume you meant
grave and not serious, but not being able to export bind-mounted /proc
surely does
Steinar H. Gunderson wrote: [Sat Jul 28 2007, 09:18:05PM EDT]
On Sat, Jul 28, 2007 at 09:15:30PM -0400, Aron Griffis wrote:
I don't want to export my /proc, I want to export a filesystem that
has proc mounted on a subdir.
But NFS exports filesystems, so at least in theory, the /proc
Package: mercurial
Version: 0.9.1-1
Severity: important
The mercurial-0.9.1 version in etch is not compatible with the on-disk
format of mercurial-0.9.3 in sid. This is a pain for anybody in
a mixed environment, particularly since other distros have already
moved forward to 0.9.3. Since there
I don't think this was ever forwarded to me. I just got curious about
Debian keychain bugs and found it myself.
I added this feature in keychain-2.6.2, so it's just waiting on Cesar
to update the Debian package to the latest version.
Aron
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
Package: mutt
Version: 1.5.9-2
Severity: important
mutt -F /dev/null
:set from=blahblah
Create a new mail and examine the From: header in the compose menu.
It's empty instead of blahblah. I tested mutt_1.5.11-2_amd64.deb
from unstable, same problem. I tested on Gentoo and found that this
1.2.5 is now available. The gentoo ebuilds suggest a pure
version-bump is possible without any changes necessary to the build
process.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
This bug was recently fixed in keychain, which is now at version
2.5.1 (not yet in Debian). See
http://dev.gentoo.org/~agriffis/keychain/ for the ChangeLog, and look
in the man-page for --inherit and --stop
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble?
Versions of keychain beyond 2.3.5 are now available in Debian. Please
close this bug.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
40 matches
Mail list logo
