Bug#575725: openssh-server: sshd looks for /usr/bin/X11/xauth instead of /usr/bin/xauth
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: x11_get_proto: /usr/bin/X11/xauth list 16.1.1.169:0.0 2/dev/null debug2: channel 0: request x11-req confirm 0 debug1: Sending command: echo x11 DISPLAY=$DISPLAY debug1: Remote: No xauth program; cannot forward with spoofing. x11 DISPLAY= There are two possible workarounds, both on the server: 1. make a symlink: cd /usr/bin; ln -s . X11 OR 2. add to /etc/ssh/sshd_config: XAuthLocation /usr/bin/xauth Here is the patch against openssh-5.3p1/debian/rules: --- debian/rules.usr-bin-xauth 2010-02-27 20:06:40.0 -0500 +++ debian/rules2010-03-28 15:12:48.0 -0400 @@ -99,3 +99,3 @@ # The deb build wants xauth; the udeb build doesn't. -confflags += --with-xauth=/usr/bin/X11/xauth +confflags += --with-xauth=/usr/bin/xauth confflags_udeb += --without-xauth -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-trunk-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages openssh-server depends on: ii adduser3.112 add and remove users and groups ii debconf [debconf-2.0] 1.5.28Debian configuration management sy ii dpkg 1.15.5.6 Debian package management system ii libc6 2.10.2-6 Embedded GNU C Library: Shared lib ii libcomerr2 1.41.11-1 common error description library ii libgssapi-krb5-2 1.8+dfsg~alpha1-7 MIT Kerberos runtime libraries - k ii libkrb5-3 1.8+dfsg~alpha1-7 MIT Kerberos runtime libraries ii libpam-modules 1.1.1-2 Pluggable Authentication Modules f ii libpam-runtime 1.1.1-2 Runtime support for the PAM librar ii libpam0g 1.1.1-2 Pluggable Authentication Modules l ii libselinux12.0.89-4 SELinux runtime shared libraries ii libssl0.9.80.9.8m-2 SSL shared libraries ii libwrap0 7.6.q-18 Wietse Venema's TCP wrappers libra ii lsb-base 3.2-23Linux Standard Base 3.2 init scrip ii openssh-blacklist 0.4.1 list of default blacklisted OpenSS ii openssh-client 1:5.3p1-3 secure shell (SSH) client, for sec ii procps 1:3.2.8-8 /proc file system utilities ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages openssh-server recommends: ii openssh-blacklist-extra 0.4.1 list of non-default blacklisted Op ii xauth 1:1.0.4-1 X authentication utility Versions of packages openssh-server suggests: pn molly-guard none (no description available) pn rssh none (no description available) pn ssh-askpass none (no description available) pn ufw none (no description available) -- debconf information: * ssh/use_old_init_script: true ssh/vulnerable_host_keys: ssh/encrypted_host_key_but_no_keygen: ssh/disable_cr_auth: false -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533723: mime-support: run-mailcap --action=cat should ignore non-copiousoutput entries
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 copiousoutput meant non-interactive stdout. Am I mistaken? I suppose we can say that between $DISPLAY and needsterminal that covers almost all possibilities. Unfortunately I know of at least one filter (unoconv) that connects to the X server (to access the openoffice server, I believe). So if we want that to work, it's not really an option to unset DISPLAY prior to running mailcap tests. Aron -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533723: mime-support: run-mailcap --action=cat should ignore non-copiousoutput entries
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 2009, 03:14:32PM 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 a --nopager option in the latest upload. So by strict RFC interpretation, a mailcap rule specifying copiousoutput implies non-interactive output on stdout, however a mailcap rule lacking copiousoutput does not strictly imply the opposite. Unfortunately this strict interpretation of the flag isn't useful for a couple reasons: 1. there's no way for the mailcap rule to know the length of the output since it depends on the input. 2. the use of a pager depends on the size of the output compared to the size of the terminal, but the mailcap doesn't know the size of the terminal either. This is probably why mutt deviates from strict RFC for the copiousoutput flag, meaning that mutt uses the flag to find rules that generate non-interactive stdout. Unfortunately I know of at least one filter (unoconv) that connects to the X server (to access the openoffice server, I believe). So if we want that to work, it's not really an option to unset DISPLAY prior to running mailcap tests. I've left cat in place though it now unsets DISPLAY. There's no perfect solution, I'm afraid. Thanks for trying to provide a solution. I understand the reasons for your choices, but unfortunately the various changes you've made fail to provide a method of achieving the result I want (which depends on copiousoutput) so I'll have to continue to maintain my fork. Aron -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533723: mime-support: run-mailcap --action=cat should ignore non-copiousoutput entries
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 a --nopager option in the latest upload. So by strict RFC interpretation, a mailcap rule specifying copiousoutput implies non-interactive output on stdout, however a mailcap rule lacking copiousoutput does not strictly imply the opposite. No, it doesn't. You can't win here. I'm confused. I wasn't intending to argue with you above. I'll try again. First, here's the definition of copiousoutput from RFC 1524: The copiousoutput field indicates that the output from the view-command will be an extended stream of output, and is to be interpreted as advice to the UA (User Agent mail-reading program) that the output should be either paged or made scrollable. Note that it is probably a mistake if needsterminal and copiousoutput are both specified. and I was inferring the following from that: 1. A mailcap run specifying copiousoutput will generate non-interactive stdout. It can't be interactive if a pager is involved, because the pager steals control of the terminal. And it must be on stdout in order for the pager to receive it. Right so far? 2. However, unfortunately the inclusion of extended in the definition above means that we can't trust *all* rules generating non-interactive stdout to include the copiousoutput flag. There might be some that generate non-interactive stdout which don't include the flag because the output is short, as judged by the author of the rule. That is what I intended by what I wrote above. I was intending to lay the groundwork for explaining why interpreting this strictly isn't useful. Mailcap was written with the intent of user interaction, not for filtering. No solution is going to work in all situations unless you deviate from the RFC. *nod* Unfortunately this strict interpretation of the flag isn't useful for a couple reasons: 1. there's no way for the mailcap rule to know the length of the output since it depends on the input. 2. the use of a pager depends on the size of the output compared to the size of the terminal, but the mailcap doesn't know the size of the terminal either. This is probably why mutt deviates from strict RFC for the copiousoutput flag, meaning that mutt uses the flag to find rules that generate non-interactive stdout. Sure, but you can't depend on the people writing the mailcap entries to flag their programs that way unless you want to create a new RFC or make it Debian policy. I agree, however you can at least depend on copiousoutput rules as working the way we need for cat without stooping to questionable tricks like unsetting $DISPLAY I can change the cat option to only match copiousoutput entries if you wish. It's a perfectly reasonable behavior given that cat isn't defined in the first place. Personally I think that would be the best, along with refraining from unsetting $DISPLAY. (In fact, it's exactly what I suggested in opening this bug.) Thanks, Aron -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550909: expect-dev: expect_multixterm says hello for no reason
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 ackowledge it.
Please make it stop or I'll break down and befriend it.
--- /usr/bin/expect_multixterm.hello2009-08-27 01:24:05.0 -0400
+++ /usr/bin/expect_multixterm 2009-10-13 20:43:02.0 -0400
@@ -986,5 +986,3 @@
if {[info exists cmdFile]} {
openFile $cmdFile
}
-
-puts hello
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (650, 'testing'), (600, 'unstable'), (550, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.28-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages expect-dev depends on:
ii expect5.43.0-19 A program that can automate intera
ii tcl8.4-dev8.4.19-4 Tcl (the Tool Command Language) v8
ii tk8.4-dev 8.4.19-4 Tk toolkit for Tcl and X11, v8.4 -
expect-dev recommends no packages.
expect-dev 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#533723: mime-support: run-mailcap --action=cat should ignore non-copiousoutput entries
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 to me cat seems to be useless because we have --action=view. I tend to agree that the current implementation of --action=cat is not useful. For my needs I created an extra script 8 astextplain #!/bin/sh unset DISPLAY run-mailcap --action=cat $* 8 instead of just using `run-mailcap --action=cat` where appropriate. This has the unfortunate effect of avoiding translators that require an X connection, for example unoconv. That's why I finally realized this method wasn't right and I opened this bug. 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 would be my preference too. To obtain the functionality as Brian implemented it, I'd probably rather something like run-mailcap --action=view --nopager since it's such a minor change from the default view action. However that isn't interesting to me so I didn't implement it. Kirill, if you're interested in trying it, I've attached my version of run-mailcap which includes my patches from #533721, #533722 and #533723. Presently I have this in my /usr/local/bin to override the default installation. Regards, Aron -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533722: (no subject)
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 reordering the code makes sense anyway, to execute perl conditionals prior to forking external processes that might not be necessary. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533723: mime-support: run-mailcap --action=cat should ignore non-copiousoutput entries
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 placed in the public domain (the only true free).
#
###
$debug=($ENV{RUN_MAILCAP_DEBUG} || 0);
$norun=0;
$etcmimetyp=/etc/mime.types;
$shrmimetyp=/usr/share/etc/mime.types;
$locmimetyp=/usr/local/etc/mime.types;
$usrmimetyp=$ENV{HOME}/.mime.types;
$xtermprgrm=/usr/bin/x-terminal-emulator; # xterm?
$defmimetyp=application/octet-stream;
$quotedsemi=chr(255);
$quotedprct=chr(254);
$retcode=0;
%patterntypes =
(
'(^|/)crontab[^/]+$' = 'text/x-crontab',
#'
'/man\d*/' = 'application/x-troff-man',
#'
'\.\d[^\.]*$' = 'application/x-troff-man',
#'
);
sub Usage {
my($error) = @_;
print STDERR $error,\n\n if $error;
print STDERR Use: $0 --action=VAL [--debug] [MIME-TYPE:[ENCODING:]]FILE
[...]\n\n;
print STDERR Options:\n;
print STDERR actionspecify what action to do on these files
(default=view)\n;
print STDERR debug be verbose about what's going on\n;
print STDERR norun just print but don't execute the command
(useful with --debug)\n;
print STDERR \n;
print STDERR Mime-Type:\n;
print STDERR any standard mime type designation in the form
class/subtype -- if\n;
print STDERR not specified, it will be determined from the filename
extension\n\n;
print STDERR Encoding:\n;
print STDERR how the file (and type) has been encoded (only \gzip\,
\bzip\, \bzip2\\n;
print STDERR and \compress\ are supported) -- if not specified, it
will be determined\n;
print STDERR from the filename extension\n\n;
exit ($error ? 1 : 0);
}
sub EncodingForFile {
my($file) = @_;
my $encoding;
if ($file =~ m/\.gz$/) { $encoding = gzip; }
if ($file =~ m/\.bz$/) { $encoding = bzip; }
if ($file =~ m/\.bz2$/) { $encoding = bzip2; }
if ($file =~ m/\.Z$/) { $encoding = compress; }
print STDERR - file \$file\ has encoding \$encoding\\n if $debug
$encoding;
return $encoding;
}
sub ReadMimetypes {
my($file) = @_;
return unless -r $file;
print STDERR - Reading mime.types file \$file\...\n if $debug;
open(MIMETYPES,$file) || die Error: could not read \$file\ -- $!\n;
while (MIMETYPES) {
chomp;
s/\#.*$//;
next if (m/^\s*$/);
$_=lc($_);
my($type,@exts) = split;
foreach (@exts) {
$mimetypes{$_} = $type unless exists $mimetypes{$_};
}
}
close MIMETYPES;
}
sub ReadMailcap {
my($file) = @_;
my $line = ;
return unless -r $file;
print STDERR - Reading mailcap file \$file\...\n if $debug;
open(MAILCAP,$file) || die Error: could not read \$file\ -- $!\n;
while (MAILCAP) {
chomp;
s/^\s+// if $line;
$line .= $_;
next unless $line;
if ($line =~ m/^\s*\#/) {
$line = ;
next;
}
if ($line =~ m/\\$/) {
$line =~ s/\\$//;
} else {
$line =~ s/\\;/$quotedsemi/go;
$line =~ s/\\%/$quotedprct/go;
push @mailcap,$line;
$line = ;
}
}
close MAILCAP;
}
sub TempFile {
my($template) = @_;
my($cmd,$head,$tail,$tmpfile);
$template = unless (defined $template);
($head,$tail) = split(/%s/,$template,2);
# $tmpfile = POSIX::tmpnam($name);
# unlink($tmpfile);
$cmd = tempfile --mode=600;
$cmd .= --prefix $head if $head;
$cmd .= --suffix $tail if $tail;
$tmpfile = `$cmd`;
chomp($tmpfile);
# $tmpfile = $ENV{TMPDIR};
# $tmpfile = /tmp unless $tmpfile;
# $tmpfile.= /$name;
# unlink($tmpfile);
return $tmpfile;
}
sub SaveStdin {
my($match) = @_;
my($tmpfile,$amt,$buf);
$tmpfile = $1 if ($match =~ m/nametemplate=(.*?)\s*($|;)/);
$tmpfile = TempFile($tmpfile);
open(TMPFILE,$tmpfile) || die Error: could not write \$tmpfile\ --
$!\n;
do {
$amt = read(STDIN,$buf,102400);
print TMPFILE $buf if $amt;
} while ($amt != 0);
close(TMPFILE);
return $tmpfile;
}
sub DecodeFile {
my($efile,$encoding,$action) = @_;
my($file,$res);
$file = $efile;
$file =~ s!^.*/!!; # remove leading directories
$file =~ s!\.[^\.]*$!!; # remove encoding extension
$file =~ s!^\.?[^\.]*!%s!; # replace name with placeholder
$file = undef if ($efile eq '-');
my $tmpfile = TempFile($file);
print STDERR - decoding \$efile\ as \$tmpfile\\n if $debug;
# unlink($tmpfile); # should still be acceptable for compose output
Bug#532342: please apply the patch
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
Bug#532342: confirmation
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 following replacement for
02-seconds.patch uses a better approach of setitimer(), the
high-resolution alternative to alarm().
--- tct-1.18.orig/src/misc/timeout.c2007-01-11 16:10:29.0 -0500
+++ tct-1.18/src/misc/timeout.c 2009-09-10 08:53:09.0 -0400
@@ -39,6 +39,8 @@
#include stdlib.h
#include unistd.h
#include stdio.h
+#include sys/time.h
+#include sys/wait.h
extern int optind;
@@ -69,10 +71,11 @@ int main(argc, argv)
int argc;
char **argv;
{
-int time_to_run;
+double time_to_run;
pid_t pid;
pid_t child_pid;
int status;
+struct itimerval itv;
progname = argv[0];
@@ -83,7 +86,7 @@ char **argv;
if ((kill_signal = atoi(*argv + 1)) = 0)
usage();
-if (argc 2 || (time_to_run = atoi(argv[0])) = 0)
+if (argc 2 || (time_to_run = atof(argv[0])) = 0)
usage();
commandname = argv[1];
@@ -105,7 +108,11 @@ char **argv;
(void) signal(SIGQUIT, terminate);
(void) signal(SIGTERM, terminate);
(void) signal(SIGALRM, terminate);
- alarm(time_to_run);
+ itv.it_value.tv_sec = (long)time_to_run;
+ itv.it_value.tv_usec = (time_to_run-itv.it_value.tv_sec)*100;
+ itv.it_interval.tv_sec = 0;
+ itv.it_interval.tv_usec = 0;
+ (void) setitimer(ITIMER_REAL, itv, NULL);
while ((pid = wait(status)) != -1 pid != child_pid)
/* void */ ;
return (pid == child_pid ? WEXITSTATUS(status) | WTERMSIG(status) : -1);
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#542815: createrepo fails: ImportError: No module named _rpm
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 module from _rpm import * ImportError: No module named _rpm -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (650, 'testing'), (600, 'unstable'), (550, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages createrepo depends on: ii python 2.5.4-2 An interactive high-level object-o ii python-libxml2 2.7.3.dfsg-2+b1 Python bindings for the GNOME XML ii python-rpm 4.7.0-9 Python bindings for RPM ii python-sqlitecachec 1.1.2-1 A fast metadata parser for YUM ii python-support 1.0.3 automated rebuilding support for P ii rpm 4.7.0-9 package manager for RPM createrepo recommends no packages. createrepo 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#533723: mime-support: run-mailcap --action=cat should ignore non-copiousoutput entries
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 --action=filter (or similar). Hi Brian, I must be missing the point of --action=cat. Its name seems to imply non-interactive stdout, but it will still run X-based viewers and needsterminal viewers. The latter seems especially strange since the user probably doesn't want an interactive curses viewer if they used --action=cat to avoid the pager. I don't mind writing the patch to use --action=filter. I just can't think of a scenario where --action=cat is interesting in that case. How did you feel I was trying to shoe-horn extra functionality? Thanks, Aron -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533721: mime-support: run-mailcap should cascade --debug to recursive instances
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 Information: Debian Release: squeeze/sid APT prefers testing APT policy: (650, 'testing'), (600, 'unstable'), (550, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.28-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash mime-support depends on no packages. Versions of packages mime-support recommends: ii file 5.03-1 Determines file type using magic mime-support 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#533721: [PATCH] cascade --debug to recursive instances of run-mailcap
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;
+$debug=($ENV{RUN_MAILCAP_DEBUG} || 0);
$norun=0;
$etcmimetyp=/etc/mime.types;
$shrmimetyp=/usr/share/etc/mime.types;
@@ -355,6 +355,9 @@
}
}
+# in case run-mailcap is called from mailcap
+$ENV{RUN_MAILCAP_DEBUG} = 1 if $debug;
+
unless ($action) {
if ($0 =~ m!(^|/)view$!) { $action=view; }
elsif ($0 =~ m!(^|/)see$!) { $action=view; }
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533722: mime-support: run-mailcap should discard non-applicable entries prior to calling test commands
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 are zero changes other than the code movement in the patch.) -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (650, 'testing'), (600, 'unstable'), (550, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.28-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash mime-support depends on no packages. Versions of packages mime-support recommends: ii file 5.03-1 Determines file type using magic mime-support 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#533723: mime-support: run-mailcap --action=cat should ignore non-copiousoutput entries
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 available is to unset the DISPLAY variable and masquerade the terminal, but that's inherently flawed because some translators (unoconv for example) need an X connection even when they're just converting to text/plain. I came to the conclusion that --action=cat should ignore mailcap entries other than copiousoutput. Consider the following example mailcap entries: text/html; firefox file://%s ; nametemplate=%s.html ; test=test -n $DISPLAY which firefox /dev/null 21 text/html; w3m file://%s ; nametemplate=%s.html ; needsterminal ; test=which w3m /dev/null 21 text/html; w3m -dump file://%s ; nametemplate=%s.html ; copiousoutput ; test=which w3m /dev/null 21 In this case, what if one wants to dump the rendered output to stdout? No-can-do with run-mailcap except with silly workarounds: $ env -u DISPLAY run-mailcap --action=cat /tmp/foo.html | cat What we really want is for --action=cat to intentionally select the copiousoutput entry. I'll follow up with a patch to fix this. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (650, 'testing'), (600, 'unstable'), (550, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.28-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash mime-support depends on no packages. Versions of packages mime-support recommends: ii file 5.03-1 Determines file type using magic mime-support 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#533722: [PATCH] move needsterminal/copiousoutput checks prior to running test
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 =~ m!(^|/)false$!i);
+
+if ($action ne 'print' $match =~ m/;\s*needsterminal\s*($|;)/ !
-t STDOUT) {
+if ($ENV{DISPLAY}) {
+$comm = $xtermprgrm -T '$file ($type)' -e $0 --action=$action
'${type}:%s';
+} else {
+print STDERR - no terminal available for rule
(needsterminal)\n if $debug;
+$fail++;
+next;
+}
+} elsif ($action eq 'view' $match =~ m/;\s*copiousoutput\s*($|;)/
$type ne 'text/plain') {
+$comm .= | $0 --action=$action text/plain:-;
+}
print STDERR - program to execute: $comm\n if $debug;
if ($match =~ m/;\s*test=(.*?)\s*($|;)/) {
@@ -453,18 +465,6 @@
}
my($tmpfile,$tmplink);
-if ($action ne 'print' $match =~ m/;\s*needsterminal\s*($|;)/ !
-t STDOUT) {
-if ($ENV{DISPLAY}) {
-$comm = $xtermprgrm -T '$file ($type)' -e $0 --action=$action
'${type}:%s';
-} else {
-print STDERR - no terminal available for rule
(needsterminal)\n if $debug;
-$fail++;
-next;
-}
-} elsif ($action eq 'view' $match =~ m/;\s*copiousoutput\s*($|;)/
$type ne 'text/plain') {
-$comm .= | $0 --action=$action text/plain:-;
-}
-
if ($file ne -) {
if ($comm =~ m/[^%]%s/) {
if ($file =~ m![^ a-z0-9,.:/@%^+=_-]!i) {
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533723: [PATCH] rewrite --action=cat to intentionally use copiousoutput
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 =~ m/;\s*needsterminal\s*($|;)/ !
-t STDOUT) {
+if ($action eq 'cat' $match !~ m/;\s*copiousoutput\s*($|;)/) {
+print STDERR - not copiousoutput, needed for cat\n if $debug;
+$fail++;
+next;
+} elsif ($action eq 'view' $match =~ m/;\s*copiousoutput\s*($|;)/) {
+if ($type eq 'text/plain') {
+print STDERR - skipping text/plain copiousoutput rule for
view\n if $debug;
+$fail++;
+next;
+} else {
+print STDERR - copiousoutput, piping back to $0 for view\n
if $debug;
+$comm .= | $0 --action=$action text/plain:-;
+}
+} elsif ($action ne 'print' $match =~ m/;\s*needsterminal\s*($|;)/
! -t STDOUT) {
if ($ENV{DISPLAY}) {
$comm = $xtermprgrm -T '$file ($type)' -e $0 --action=$action
'${type}:%s';
} else {
@@ -447,8 +460,6 @@
$fail++;
next;
}
-} elsif ($action eq 'view' $match =~ m/;\s*copiousoutput\s*($|;)/
$type ne 'text/plain') {
-$comm .= | $0 --action=$action text/plain:-;
}
print STDERR - program to execute: $comm\n if $debug;
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533723: note regarding patch
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 listmas...@lists.debian.org
Bug#522001: ping
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
Bug#367301: patch on klibc ML
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
Bug#522001: /usr/bin/run-mailcap: run-mailcap forkbomb (patch provided)
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 -0400
+++ /usr/bin/run-mailcap.agriffis 2009-03-30 23:59:29.0 -0400
@@ -455,7 +455,7 @@
$fail++;
next;
}
-} elsif ($action eq 'view' $match =~ m/;\s*copiousoutput\s*($|;)/) {
+} elsif ($action eq 'view' $match =~ m/;\s*copiousoutput\s*($|;)/
$type ne 'text/plain') {
$comm .= | $0 --action=$action text/plain:-;
}
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (650, 'testing'), (600, 'unstable'), (550, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.28-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
mime-support depends on no packages.
Versions of packages mime-support recommends:
ii file 4.26-2 Determines file type using magic
mime-support 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#503298: libengine-pkcs11-openssl: engine-pkcs11-0.1.4 fails in get_pin
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 for smartcard users that libengine-pkcs11-openssl-0.1.4 fails to ask for a PIN, often rendering the smartcard locked. Thanks! -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (650, 'testing'), (600, 'unstable'), (550, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.25-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libengine-pkcs11-openssl depends on: ii libc62.7-10 GNU C Library: Shared libraries ii libp11-0 0.2.3-2 pkcs#11 convenience library ii libssl0.9.8 0.9.8g-10.1 SSL shared libraries libengine-pkcs11-openssl recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#488752: ping?
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]
Bug#488752: pulseaudio: initscript returns wrong status
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:
--- /etc/init.d/pulseaudio.agriffis 2008-06-30 21:29:58.0 -0400
+++ /etc/init.d/pulseaudio 2008-06-30 21:30:03.0 -0400
@@ -26,8 +26,10 @@
test $PULSEAUDIO_SYSTEM_START != 1 exit 0
pulseaudio_start () {
+ declare status
log_begin_msg Starting PulseAudio Daemon
start-stop-daemon -x $DAEMON -p $PIDFILE --start -- --system
--daemonize --high-priority --log-target=syslog
--disallow-module-loading=$DISALLOW_MODULE_LOADING
+ status=$?
if [ -e /var/run/pulse/.esd_auth ]; then
chown pulse:pulse-access /var/run/pulse/.esd_auth
chmod 640 /var/run/pulse/.esd_auth
@@ -36,7 +38,7 @@
chown pulse:pulse-access /var/run/pulse/.pulse-cookie
chmod 640 /var/run/pulse/.pulse-cookie
fi
- log_end_msg $?
+ log_end_msg $status
}
pulseaudio_stop () {
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (650, 'testing'), (600, 'unstable'), (550, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages pulseaudio depends on:
ii adduser 3.108 add and remove users and groups
ii libasound21.0.16-2 ALSA library
ii libasyncns0 0.3-1 Asyncronous name service query lib
ii libc6 2.7-10 GNU C Library: Shared libraries
ii libcap1 1:1.10-14 support for getting/setting POSIX.
ii libdbus-1-3 1.2.1-2simple interprocess messaging syst
ii libflac8 1.2.1-1.2 Free Lossless Audio Codec - runtim
ii libltdl3 1.5.26-4 A system independent dlopen wrappe
ii libogg0 1.1.3-4Ogg Bitstream Library
ii liboil0.3 0.3.14-5 Library of Optimized Inner Loops
ii libpulsecore5 0.9.10-2 PulseAudio sound server core
ii libsamplerate00.1.3-1audio rate conversion library
ii libsndfile1 1.0.17-4 Library for reading/writing audio
ii libwrap0 7.6.q-15 Wietse Venema's TCP wrappers libra
ii lsb-base 3.2-12 Linux Standard Base 3.2 init scrip
Versions of packages pulseaudio recommends:
ii gstreamer0.10-pulseaudio 0.9.7-2 GStreamer plugin for PulseAudio
ii libasound2-plugins 1.0.16-1+b1 ALSA library additional plugins
ii padevchooser 0.9.3-2 PulseAudio Device Chooser
ii paprefs 0.9.6-2 PulseAudio Preferences
ii pulseaudio-esound-compat 0.9.10-2PulseAudio ESD compatibility layer
pn pulseaudio-module-halnone (no description available)
ii pulseaudio-module-x110.9.10-2X11 module for PulseAudio sound se
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#488754: initscript should wait for pulseaudio to stop
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 --retry option to
start-stop-daemon. With the following patch, the initscript will
wait 3 seconds for pulseaudio to stop, and report the final status
appropriately. Note this is *up to* 3 seconds; start-stop-daemon
will poll regularly and exit early if possible.
--- /etc/init.d/pulseaudio.agriffis 2008-06-30 22:25:11.0 -0400
+++ /etc/init.d/pulseaudio 2008-06-30 22:24:29.0 -0400
@@ -42,9 +42,15 @@
}
pulseaudio_stop () {
+ declare status
log_begin_msg Stopping PulseAudio Daemon
- start-stop-daemon -p $PIDFILE --stop || echo -n ... pulseaudio is not
running
- log_end_msg $?
+ start-stop-daemon -p $PIDFILE --stop --retry TERM/3
+ status=$?
+ case $status in
+ 1) echo -n ... pulseaudio is not running ;;
+ 2) echo -n ... pulseaudio still running after timeout ;;
+ esac
+ log_end_msg $status
}
case $1 in
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (650, 'testing'), (600, 'unstable'), (550, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages pulseaudio depends on:
ii adduser 3.108 add and remove users and groups
ii libasound21.0.16-2 ALSA library
ii libasyncns0 0.3-1 Asyncronous name service query lib
ii libc6 2.7-10 GNU C Library: Shared libraries
ii libcap1 1:1.10-14 support for getting/setting POSIX.
ii libdbus-1-3 1.2.1-2simple interprocess messaging syst
ii libflac8 1.2.1-1.2 Free Lossless Audio Codec - runtim
ii libltdl3 1.5.26-4 A system independent dlopen wrappe
ii libogg0 1.1.3-4Ogg Bitstream Library
ii liboil0.3 0.3.14-5 Library of Optimized Inner Loops
ii libpulsecore5 0.9.10-2 PulseAudio sound server core
ii libsamplerate00.1.3-1audio rate conversion library
ii libsndfile1 1.0.17-4 Library for reading/writing audio
ii libwrap0 7.6.q-15 Wietse Venema's TCP wrappers libra
ii lsb-base 3.2-12 Linux Standard Base 3.2 init scrip
Versions of packages pulseaudio recommends:
ii gstreamer0.10-pulseaudio 0.9.7-2 GStreamer plugin for PulseAudio
ii libasound2-plugins 1.0.16-1+b1 ALSA library additional plugins
ii padevchooser 0.9.3-2 PulseAudio Device Chooser
ii paprefs 0.9.6-2 PulseAudio Preferences
ii pulseaudio-esound-compat 0.9.10-2PulseAudio ESD compatibility layer
pn pulseaudio-module-halnone (no description available)
ii pulseaudio-module-x110.9.10-2X11 module for PulseAudio sound se
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#436452: fixed in 7.1.125
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]
Bug#436452: termresponse fails in vimdiff
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 least, as the following autocmd demonstrates: augroup ag_setcolors autocmd! autocmd TermResponse * echom v:termresponse augroup END However vimdiff seems to abort the TermResponse autocmd. Even though v:termresponse is set, the above autocmd never fires. --- System information. --- Architecture: i386 Kernel: Linux 2.6.21-2-686 Debian Release: lenny/sid 650 testing security.debian.org 650 testing ftp.us.debian.org 650 testing debian-multimedia.fx-services.com 600 unstabledebian-multimedia.fx-services.com 1002 unstablen01se.net --- Package information. --- Depends (Version) | Installed =-+- vim-gui-common(= 1:7.1-022+1) | 1:7.1-022+1 vim-common(= 1:7.1-022+1) | 1:7.1-022+1 vim-runtime (= 1:7.1-022+1) | 1:7.1-022+1 libart-2.0-2 (= 2.3.18) | 2.3.19-3 libatk1.0-0 (= 1.13.2) | 1.18.0-2 libbonobo2-0 (= 2.15.0) | 2.18.0-2 libbonoboui2-0(= 2.15.1) | 2.18.0-5 libc6 (= 2.5-5) | 2.6-2 libcairo2 (= 1.4.0) | 1.4.10-1 libfontconfig1 (= 2.4.0) | 2.4.2-1.2 libgconf2-4 (= 2.13.5) | 2.18.0.1-3 libglib2.0-0 (= 2.12.9) | 2.12.13-1 libgnome-keyring0(= 0.8) | 0.8.1-2 libgnome2-0 (= 2.17.3) | 2.18.0-4 libgnomecanvas2-0 (= 2.11.1) | 2.14.0-3 libgnomeui-0 (= 2.17.1) | 2.18.1-2 libgnomevfs2-0 (= 1:2.17.90) | 1:2.18.1-2 libgpmg1(= 1.19.6-1) | 1.19.6-25 libgtk2.0-0(= 2.10.12-3) | 2.10.13-1 libice6 (= 1:1.0.0) | 2:1.0.3-3 libncurses5(= 5.4-5) | 5.6+20070716-1 liborbit2 (= 1:2.14.1) | 1:2.14.7-0.1 libpango1.0-0 (= 1.16.4) | 1.16.4-1 libperl5.8 (= 5.8.8) | 5.8.8-7 libpopt0(= 1.10) | 1.10-3 libruby1.8 (= 1.8.6) | 1.8.6.36-1 libsm6| 2:1.0.3-1+b1 libx11-6 | 2:1.0.3-7 libxcursor1( 1.1.2) | 1:1.1.8-2 libxext6 | 1:1.0.3-2 libxfixes3 (= 1:4.0.1) | 1:4.0.3-2 libxi6| 2:1.1.1-1 libxinerama1 | 1:1.0.2-1 libxrandr2 (= 2:1.2.0) | 2:1.2.1-1 libxrender1 | 1:0.9.2-1 libxt6| 1:1.0.5-3 python2.4 (= 2.3.90) | 2.4.4-5 tcl8.4 (= 8.4.5) | 8.4.12-1.1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#435056: nfs server hangs on /proc bind-mount
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 unreproducible. Does this fix it for you too? If I put the server restart in a loop, the client makes slow progress. Restarting just once does not alleviate the problem forever. It's possible that I'm seeing it hang once per subdirectory, since I have a number of mounts under the export. I would need to test more to discover. This is the loop I used: while true; do /etc/init.d/nfs-kernel-server restart sleep 5 done Thanks for reproducing it. I'm glad it's not something peculiar to my configuration. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#435056: nfs server hangs on /proc bind-mount
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 10.0.0.0/16(rw,no_root_squash,async,no_subtree_check) 2. The client can see the content of that filesystem, for example: /foo/bar/baz.txt 3. The server now mounts a directory: mount /dev/sdb1 /foo/bar 4. Now at this point, the server should see new content on /foo/bar, but the client should continue to see the underlying content. In other words, the client can still access /foo/bar/baz.txt HOWEVER, in some cases at least, the NFS connection is instead hanging on step 4. The client sends a LOOKUP on /foo/bar and the server never responds. The client retransmits the LOOKUP indefinitely. This seems to be easy to demostrate by mounting procfs on /foo/bar, but I've now seen it using other filesystems. The only reason I use the chroot example is because it is common to export a chroot environment as nfs-root. The clients see only the one filesystem, yes, but the server mounts additional directories so that it's possible to build and install software more easily in the server environment. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#435056: nfs server hangs on /proc bind-mount
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 bind-mounts seem to be unaffected (tested with lvm volumes) server -- mkdir -p /test/proc mount -o bind /proc /test/proc echo '/test 10.0.0.0/16(rw,no_root_squash,async,no_subtree_check)' /etc/exports exportfs -a client -- mkdir /test mount server:/test /test /bin/ls /test # works /bin/ls /test/proc # hangs The problem goes away if I directly mount proc on /test/proc instead of using a bind-mount. --- System information. --- Architecture: i386 Kernel: Linux 2.6.21-2-686 Debian Release: lenny/sid 650 testing security.debian.org 650 testing ftp.us.debian.org 650 testing debian-multimedia.fx-services.com 600 unstabledebian-multimedia.fx-services.com 1002 unstablen01se.net --- Package information. --- Depends (Version) | Installed ==-+-= nfs-common (= 1:1.0.8-1) | 1:1.1.0-11 ucf| 3.001 lsb-base (= 1.3-9ubuntu3) | 3.1-23.1 libblkid1 (= 1.39-1) | 1.39+1.40-WIP-2006.11.14+dfsg-2 libc6 (= 2.5-5) | 2.6-2 libcomerr2 (= 1.33-3) | 1.39+1.40-WIP-2006.11.14+dfsg-2 libgssapi2 | 0.11-1 libkrb53 (= 1.6.dfsg.1) | 1.6.dfsg.1-6 libnfsidmap2 | 0.19-0+b1 librpcsecgss3 | 0.14-2 libwrap0 | 7.6.dbs-13 libblkid1 (= 1.39+1.40-WIP-2006.11.14+dfsg-2) | 1.39+1.40-WIP-2006.11.14+dfsg-2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#435056: nfs server hangs on /proc bind-mount
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 scenario is a common one for NFS-root environments. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#435056: nfs server hangs on /proc bind-mount
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 not make the entire package unusable or nearly so. I don't want to export my /proc, I want to export a filesystem that has proc mounted on a subdir. Consider an NFS-root structure: /chroots/foo/proc /chroots/foo/sys /chroots/foo/usr /chroots/foo/lib /chroots/foo/etc /chroots/foo/dev /chroots/foo/tmp This is exported via /chroots/foo 10.0.0.0/8(ro,no_root_squash,no_subtree_check) (It's read-only because the client uses unionfs to make a writeable tmpfs over the NFS-root.) On the server I like to do fast builds and such. So I treat it like a chroot there and bind-mount important dirs. /dev/mapper/raid_vg-foo /chroots/foo ext3 noatime 0 2 /dev/chroots/foo/dev none bind 0 0 /dev/pts/chroots/foo/dev/pts devpts defaults 0 0 /dev/shm/chroots/foo/dev/shm none bind 0 0 /home/agriffis /chroots/foo/home/agriffis none bind 0 0 /proc /chroots/foo/proc none bind 0 0 /sys/chroots/foo/sys none bind 0 0 /tmp/chroots/foo/tmp none bind 0 0 This is quite a common scenario when working on large-scale NFS-root installations. This worked well with 1.0.9 but has stopped working with 1.1.0 because of the NFS server freeze when it encounters the bind-mounted proc dir. In fact I determined it also freezes when proc is mounted directly, nevermind bind-mounting. My original report said that it worked in that configuration, but it doesn't. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#435056: nfs server hangs on /proc bind-mount
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 in there should be ignored completely unless you export it. Exactly. But instead it's hanging /chroots/foo 10.0.0.0/8(ro,no_root_squash,no_subtree_check) In fact I determined it also freezes when proc is mounted directly, nevermind bind-mounting. My original report said that it worked in that configuration, but it doesn't. Have you tried changing to subtree_check? I haven't yet. I thought no_subtree_check only referred to permissions, and nohide refers to sub-filesystems? I was also using no_subtree_check on 1.0.9 with this configuration. (Note the simple reproducer I gave in the start of this bug report means that you also can test ;-) Is it mountd or the kernel that freezes? Not sure. It can be worked around by continuously restarting the nfs server, so that sounds like userland. In wireshark it shows as a LOOKUP on /proc, and the server never replies. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413869: update etch mercurial from 0.9.1 to 0.9.3
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 are no outstanding bugs against 0.9.3 in dbts, it seems reasonable to move etch forward to 0.9.3 before release. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (650, 'testing'), (600, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.20.1 Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Versions of packages mercurial depends on: ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii python 2.4.4-2 An interactive high-level object-o ii python-support 0.5.6automated rebuilding support for p ii python2.4 2.4.4-2 An interactive high-level object-o Versions of packages mercurial recommends: ii rcs 5.7-18 The GNU Revision Control System pn tk8.4 | wish none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#296382: Fixed in 2.6.2
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 subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#338237: mutt: ignores set from=...
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 problem doesn't exist there. The problem can't be worked around with my_hdr because that overrides reverse_name, which isn't desirable. In other words, the From: line is normally set using this priority: 1. my_hdr (for example in a send-hook) 2. reverse_name (for replies only) 3. fallback to from setting In Debian, #3 is broken. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-em64t-p4-smp Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Versions of packages mutt depends on: ii exim4 4.54-1 metapackage to ease exim MTA (v4) ii exim4-daemon-light [mail-tran 4.54-1 lightweight exim MTA (v4) daemon ii libc6 2.3.5-6GNU C Library: Shared libraries an ii libdb4.3 4.3.28-2 Berkeley v4.3 Database Libraries [ ii libgnutls11 1.0.16-14 GNU TLS library - runtime library ii libidn11 0.5.18-1 GNU libidn library, implementation ii libncursesw5 5.4-9 Shared libraries for terminal hand ii libsasl2 2.1.19-1.5 Authentication abstraction library Versions of packages mutt recommends: ii locales 2.3.5-6GNU C Library: National Language ( ii mime-support 3.35-1 MIME files 'mime.types' 'mailcap -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323922: now 1.2.5 is available
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]
Bug#155052: fixed in keychain 2.5.0
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? Contact [EMAIL PROTECTED]
Bug#246967: please close this bug
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]
