Bug#498819: doesn't honor $HOME while reading .enscriptrc
Ivan Shmakov i...@theory.asu.ru writes: The `enscript' command currently doesn't honor the value of the HOME environment variable while reading its configuration, and uses the value from the user's passwd(5) entry instead, … As of 1.6.5.2-1, I no longer observe this bug. Consider, e. g.: $ HOME=$(mktemp -dt) strace enscript -o /dev/null /dev/null 21 \ | grep -F -- tmp. open(/tmp/tmp.jpoqawmSoF/.enscriptrc, O_RDONLY) = -1 ENOENT (No such file or directory) $ TIA. -- FSF associate member #7257 pgpJnO7agdM0M.pgp Description: PGP signature
Bug#191525: mgetty-docs inittab example is self-contradictory
Andreas Barth a...@not.so.argh.org writes: […] The mgetty-Package does not provide any entries in /etc/inittab, neither removes them after de-installation. So it should be best to remove these four lines. But it could be formed as a wishlist-entry that mgetty does one day both (as e.g. isdnutils does). It's my opinion that inittab(5) is such a fragile file that it shouldn't be touched unless explicitly requested. Given that editing inittab(5) manually isn't a big deal, I'd suggest marking this bug with wontfix. TIA. -- FSF associate member #7257 pgpqO5NTCbOvV.pgp Description: PGP signature
Bug#498819: Bug#191525: mgetty-docs inittab example is self-contradictory
Ivan Shmakov oneing...@gmail.com writes: […] It's my opinion that inittab(5) is such a fragile file that it shouldn't be touched unless explicitly requested. [Okay, I've messed it up. Resent to 191525@. Apologies for the inconvenience.] […] -- FSF associate member #7257 pgpoAfD36AQYk.pgp Description: PGP signature
Bug#645293: doesn't allow for an IPv6 HTTP proxy
Package: aria2
Version: 1.12.1-2
Tags: ipv6
Apparently, aria2c(1) doesn't allow for an IPv6 HTTP proxy.
I've identified the following two cases:
• should the HTTP proxy's host name (as per, e. g., the
http_proxy environment variable) resolve to both IPv6 and
legacy IPv4 addresses (IOW, has both and A DNS records),
aria2c(1) will try to use the IPv4 address unconditionally,
like:
$ http_proxy=http://httpproxy.example.net:3128/ \
strace -t -- \
aria2c --log= http://www.google.com/ \
21 | grep -F -A1 -- connect\(
05:02:29 connect(6, {sa_family=AF_INET6, sin6_port=htons(53),
inet_pton(AF_INET6, 2001:db8::d:17:5, sin6_addr), sin6_flowinfo=0,
sin6_scope_id=0}, 28) = 0
05:02:29 sendto(6, }I\1\0\0\1\0\0\0\0\0\0\thttpproxy\7example\3ne..., 39,
MSG_NOSIGNAL, NULL, 0) = 39
--
05:02:29 connect(6, {sa_family=AF_INET, sin_port=htons(3128),
sin_addr=inet_addr(192.0.2.34)}, 16) = -1 EINPROGRESS (Operation now in
progress)
05:02:29 epoll_ctl([…]) = 0
--
05:02:29 connect(6, {sa_family=AF_INET6, sin6_port=htons(53),
inet_pton(AF_INET6, 2001:db8::d:17:5, sin6_addr), sin6_flowinfo=0,
sin6_scope_id=0}, 28) = 0
05:02:29 sendto(6, \303v\1\0\0\1\0\0\0\0\0\0\thttpproxy\7example\3ne..., 39,
MSG_NOSIGNAL, NULL, 0) = 39
--
05:02:29 connect(6, {sa_family=AF_INET, sin_port=htons(3128),
sin_addr=inet_addr(192.0.2.34)}, 16) = -1 EINPROGRESS (Operation now in
progress)
05:02:29 epoll_ctl([…]) = 0
--
[…]
$
• should the HTTP proxy paramenter be set to reference an IPv6
address directly, aria2c(1) will simply silently (the only
message would be in the log file, not created by default, and
at the level of DEBUG) ignore it, and will try to contact the
server hosting the resource specified directly:
$ http_proxy=http://\[2001:db8::222\]:3128/ \
strace -t -- \
aria2c --log= http://www.google.com/ \
21 | grep -F -A1 -- connect\(
05:11:08 connect(6, {sa_family=AF_INET6, sin6_port=htons(53),
inet_pton(AF_INET6, 2001:db8::d:17:5, sin6_addr), sin6_flowinfo=0,
sin6_scope_id=0}, 28) = 0
05:11:08 sendto(6,
\203\247\1\0\0\1\0\0\0\0\0\0\3www\6google\3com\0\0\1\0\1..., 32,
MSG_NOSIGNAL, NULL, 0) = 32
--
05:11:08 connect(6, {sa_family=AF_INET, sin_port=htons(80),
sin_addr=inet_addr(209.85.169.99)}, 16) = -1 EINPROGRESS (Operation now in
progress)
05:11:08 epoll_ctl(5, EPOLL_CTL_ADD, 6, {EPOLLIN, {u32=69847744,
u64=140497040034496}}) = 0
--
05:11:09 connect(7, {sa_family=AF_INET6, sin6_port=htons(53),
inet_pton(AF_INET6, 2001:db8::d:17:5, sin6_addr), sin6_flowinfo=0,
sin6_scope_id=0}, 28) = 0
05:11:09 sendto(7, o\223\1\0\0\1\0\0\0\0\0\0\3www\6google\2ru\0\0\1\0\1...,
31, MSG_NOSIGNAL, NULL, 0) = 31
$
--
FSF associate member #7257
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644267: fails to access a read-only folder
Package: mailutils-mh Version: 1:2.2+dfsg1-3+b1 The mhn command fails to access a read-only folder, e. g.: $ which mhn /usr/bin/mailutils-mh $ mhn +foo 12345 $ echo $? 0 $ Running mhn under strace(1) reveals that it tries, unsuccessfully, to open(2) ~/Mail/foo/12345 with O_RDWR. Arguably, it should've used O_RDONLY instead. The scan command produces a list devoid of any information for this folder, except for the message numbers. Also, for no reason obvious to me, both commands try to access ~/Mail/foo/1 (which is the first message in the folder) just as well. The operation on read-only folders is a generic prerequisite of accessing shared mail folders (such as, e. g., mailing list or newsgroup archives.) -- FSF associate member #7257 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#641315: ITP: opendap -- Project for a Network Data Access Protocol
Already in Debian, as it seems. --cut: http://packages.debian.org/sid/libdap10 -- Open-source Project for a Network Data Access Protocol library OPeNDAP provides software that allows you to access data over the internet, from programs that weren't originally designed for that purpose, as well as some that were. While OPeNDAP is the original developer of the Data Access protocol which its software uses, many other groups have adopted DAP and provide compatible clients, servers and software development kits. --cut: http://packages.debian.org/sid/libdap10 -- -- FSF associate member #7257 Coming soon: Software Freedom Day http://mail.sf-day.org/lists/listinfo/ planning-ru (ru), sfd-discuss (en) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#634947: missing Homepage: in debian/control
Source: pdns Version: 2.9.22-9 Severity: wishlist Please consider adding Homepage: http://www.powerdns.com/ to debian/control. -- FSF associate member #7257 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#619355: #619355 lynx fails to stop on SIGTSTP (C-z)
Ivan Shmakov i...@gray.siamics.net writes:
[…]
I should probably try to compare strace(1)'s…
I've grep'ed the strace for “rt_sig”. The results for the first
and second SIGTSTP are MIME'd.
And there's a difference:
• first SIGTSTP:
rt_sigaction(SIGTSTP, {0x7f061efbf800, [], SA_RESTORER|SA_RESTART,
0x7f061e5461e0}, NULL, 8) = 0
• second SIGTSTP:
rt_sigaction(SIGTSTP, {SIG_IGN}, NULL, 8) = 0
Do I understand it correctly that the SIGTSTP signal handler is
not properly reset in the latter case?
--
FSF associate member #7257
rt_sigprocmask(SIG_BLOCK, [ALRM WINCH], [TSTP], 8) = 0
rt_sigprocmask(SIG_BLOCK, [TTOU], NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [TSTP TTOU], NULL, 8) = 0
rt_sigaction(SIGTSTP, {SIG_DFL}, {0x7f061efbf800, [], SA_RESTORER|SA_RESTART,
0x7f061e5461e0}, 8) = 0
rt_sigaction(SIGTSTP, {0x7f061efbf800, [], SA_RESTORER|SA_RESTART,
0x7f061e5461e0}, NULL, 8) = 0
rt_sigaction(SIGTSTP, {SIG_IGN}, {0x7f061efbf800, [], SA_RESTORER|SA_RESTART,
0x7f061e5461e0}, 8) = 0
rt_sigaction(SIGWINCH, {0x7f0617332330, [], SA_RESTORER, 0x7f061e5461e0},
{0x443ee0, [WINCH], SA_RESTORER|SA_RESTART, 0x7f061e5461e0}, 8) = 0
rt_sigaction(SIGTSTP, {SIG_IGN}, {SIG_IGN}, 8) = 0
rt_sigaction(SIGTSTP, {0x7f061efbf800, [], SA_RESTORER|SA_RESTART,
0x7f061e5461e0}, NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [TSTP], NULL, 8) = 0
rt_sigreturn(0x2) = 0
rt_sigprocmask(SIG_BLOCK, [ALRM WINCH], [TSTP], 8) = 0
rt_sigprocmask(SIG_BLOCK, [TTOU], NULL, 8) = 0
rt_sigaction(SIGTSTP, {SIG_IGN}, NULL, 8) = 0
rt_sigaction(SIGWINCH, {0x443ee0, [WINCH], SA_RESTORER|SA_RESTART,
0x7f061e5461e0}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [TSTP TTOU], NULL, 8) = 0
rt_sigaction(SIGTSTP, {SIG_DFL}, {SIG_IGN}, 8) = 0
rt_sigaction(SIGTSTP, {SIG_IGN}, NULL, 8) = 0
rt_sigaction(SIGTSTP, {SIG_IGN}, {SIG_IGN}, 8) = 0
rt_sigaction(SIGWINCH, {0x7f0617332330, [], SA_RESTORER, 0x7f061e5461e0},
{0x443ee0, [WINCH], SA_RESTORER|SA_RESTART, 0x7f061e5461e0}, 8) = 0
rt_sigaction(SIGTSTP, {SIG_IGN}, {SIG_IGN}, 8) = 0
rt_sigaction(SIGTSTP, {SIG_IGN}, NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [TSTP], NULL, 8) = 0
rt_sigreturn(0x2) = 0
Bug#619355: #619355 lynx fails to stop on SIGTSTP (C-z)
Thomas Dickey dic...@his.com writes: On Thu, 19 May 2011, Ivan Shmakov wrote: Thomas Dickey dic...@his.com writes: This seems to work for me (trying both tcsh and bash). Can you provide more details (perhaps locale, shell/version, etc). I cannot reproduce the issue on a few of fresh Squeeze incarnations, either. However, the issue readily manifests itself on a Squeeze system which still has some Lenny packages yet to be upgraded. (Of those, only debconf is in the lynx-cur Depends: list.) So, I guess that there's some library package used by Lynx that causes the problem. I'm going to try my luck tracking it down. thanks - it doesn't sound simple to track down (though I'd assume it's either in the bash dependencies, or lynx's). Well, on a host on which such an condition occurs, I also have a chroot environment with Debian Squeeze installed. Unsurprisingly, running Lynx there doesn't lead to the problem. What I've found surprising, however, is that if I run chroot environment's Lynx (using all the libraries installed there) without actually chroot'ing, it also fails to respond to SIGTSTP correctly! I've run chroot'ed Lynx) like: • using schroot(1) (reacts to SIGTSTP): $ LC_ALL=C schroot -c squeeze -- /usr/bin/lynx (note that no Shell is involved there); • using LD_LIBRARY_PATH (fails to react to SIGTSTP): $ LC_ALL=C LD_LIBRARY_PATH=$p/lib:$p/usr/lib \ $p/lib/ld-linux-x86-64.so.2 $p/usr/bin/lynx.cur (locale is disabled so that the base system's /usr/lib/gconv/ isn't used; I've also used ld-linux.so from chroot.) I've also MIME'd the /proc/LYNXID/maps file for the latter case. Seemingly, the above rules out the possibility of a broken Shell or library. I should probably try to compare strace(1)'s… […] -- FSF associate member #7257 0040-00537000 r-xp fc:0d 24726 /srv/chroot/2011-01-25/usr/bin/lynx.cur 00737000-00764000 rw-p 00137000 fc:0d 24726 /srv/chroot/2011-01-25/usr/bin/lynx.cur 00764000-007d3000 rw-p 00764000 00:00 0 7f6f15957000-7f6f1595c000 r-xp fc:0d 8473 /srv/chroot/2011-01-25/usr/lib/libgpm.so.2.0.0 7f6f1595c000-7f6f15b5c000 ---p 5000 fc:0d 8473 /srv/chroot/2011-01-25/usr/lib/libgpm.so.2.0.0 7f6f15b5c000-7f6f15b5d000 rw-p 5000 fc:0d 8473 /srv/chroot/2011-01-25/usr/lib/libgpm.so.2.0.0 7f6f15b5d000-7f6f15b6 rw-p 7f6f15b5d000 00:00 0 7f6f15b6-7f6f15b63000 r-xp fc:0d 8693 /srv/chroot/2011-01-25/usr/lib/libgpg-error.so.0.4.0 7f6f15b63000-7f6f15d62000 ---p 3000 fc:0d 8693 /srv/chroot/2011-01-25/usr/lib/libgpg-error.so.0.4.0 7f6f15d62000-7f6f15d63000 rw-p 2000 fc:0d 8693 /srv/chroot/2011-01-25/usr/lib/libgpg-error.so.0.4.0 7f6f15d63000-7f6f15d73000 r-xp fc:0d 8698 /srv/chroot/2011-01-25/usr/lib/libtasn1.so.3.1.9 7f6f15d73000-7f6f15f72000 ---p 0001 fc:0d 8698 /srv/chroot/2011-01-25/usr/lib/libtasn1.so.3.1.9 7f6f15f72000-7f6f15f73000 rw-p f000 fc:0d 8698 /srv/chroot/2011-01-25/usr/lib/libtasn1.so.3.1.9 7f6f15f73000-7f6f15f74000 rw-p 7f6f15f73000 00:00 0 7f6f15f74000-7f6f15f76000 r-xp fc:0c 26726 /srv/chroot/2011-01-25/lib/libdl-2.11.2.so 7f6f15f76000-7f6f16176000 ---p 2000 fc:0c 26726 /srv/chroot/2011-01-25/lib/libdl-2.11.2.so 7f6f16176000-7f6f16177000 r--p 2000 fc:0c 26726 /srv/chroot/2011-01-25/lib/libdl-2.11.2.so 7f6f16177000-7f6f16178000 rw-p 3000 fc:0c 26726 /srv/chroot/2011-01-25/lib/libdl-2.11.2.so 7f6f16178000-7f6f162d r-xp fc:0c 26728 /srv/chroot/2011-01-25/lib/libc-2.11.2.so 7f6f162d-7f6f164cf000 ---p 00158000 fc:0c 26728 /srv/chroot/2011-01-25/lib/libc-2.11.2.so 7f6f164cf000-7f6f164d3000 r--p 00157000 fc:0c 26728 /srv/chroot/2011-01-25/lib/libc-2.11.2.so 7f6f164d3000-7f6f164d4000 rw-p 0015b000 fc:0c 26728 /srv/chroot/2011-01-25/lib/libc-2.11.2.so 7f6f164d4000-7f6f164d9000 rw-p 7f6f164d4000 00:00 0 7f6f164d9000-7f6f164e2000 r-xp fc:0c 26695 /srv/chroot/2011-01-25/lib/libbsd.so.0.2.0 7f6f164e2000-7f6f166e2000 ---p 9000 fc:0c 26695 /srv/chroot/2011-01-25/lib/libbsd.so.0.2.0 7f6f166e2000-7f6f166e3000 rw-p 9000 fc:0c 26695 /srv/chroot/2011-01-25/lib/libbsd.so.0.2.0 7f6f166e3000-7f6f166e4000 rw-p 7f6f166e3000 00:00 0 7f6f166e4000-7f6f16758000 r-xp fc:0d 8691 /srv/chroot/2011-01-25/usr/lib/libgcrypt.so.11.5.3 7f6f16758000-7f6f16958000 ---p 00074000 fc
Bug#619355: #619355 lynx fails to stop on SIGTSTP (C-z)
Thomas Dickey dic...@his.com writes:
[…]
Lynx is using ncurses for handling SIGTSTP most of the time. It
sets/unsets a handler when it is doing a system() call. If your test
scenario doesn't run any external programs, then perhaps the problem
is in ncurses (or the way lynx uses it).
Somehow, “ncurses” is synonymous with “environment variables” to
me. Indeed, running lynx within a clean environment, via either
schroot(1) or env(1) ($ env -i TERM=$TERM lynx), resulted in
apparently correct SIGTSTP handling.
Several iterations after, I've found a minimal ${LYNX_CFG}
example that leads to the problem I've described:
$ cat $LYNX_CFG
INCLUDE:/etc/lynx-cur/lynx.cfg
USE_MOUSE:TRUE
$
(I've added USE_MOUSE:TRUE to my ${LYNX_CFG} almost five years
ago, and it was there ever since, even though I haven't actually
used it much.)
--
FSF associate member #7257
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#470936: VT switching results in scrambled colors with -depth 24
Cyril Brulebois k...@debian.org writes: Hi, Igor Shmakov ihammers@gmail.com (14/12/2008): I'm experiencing the same problem with X.org from Debian Lenny on the similar (Radeon HD 2400 XT) hardware. is it better in squeeze, sid, or experimental? The problem of scrambled colors with -depth 24 seem to be vanished by 1:2.3.0-3, thanks. (Though I'm more inclined to use xserver-xorg-video-radeonhd for it works for a long time now.) However, there still is a similarly-looking issue with -depth 16. TIA. $ lspci | grep -F Radeon\ HD | base64 04:00.0 VGA compatible controller: ATI Technologies Inc RV610 video device [Radeon HD 2400 PRO] 04:00.1 Audio device: ATI Technologies Inc RV610 audio device [Radeon HD 2400 PRO] $ -- FSF associate member #7257 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629118: allow the configuration file location to be overridden
Package: drraw
Version: 2.2b2-3
Severity: wishlist
X-Debbugs-Cc: Igor Shmakov ihammers@gmail.com
Currently, drraw could only read the system configuration file,
located at /etc/drraw/drraw.conf:
50 # The configuration file is expected to be found in the same directory
51 # as drraw itself. You may customize this to be elsewhere.
52 my $config = /etc/drraw/drraw.conf; # Untaint
However, it may sometimes be useful to allow for either several
drraw instances, or an instance configured by an unprivileged
user (e. g., for testing purposes.)
This configuration could, actually, be quite easy to set up,
like:
$ cat PUBLIC_HTML/drraw/.htaccess
Order allow,deny
Allow from all
FilesMatch ^drraw\.cgi$
SetHandler cgi-script
ForceType text/html
/FilesMatch
$ cat PUBLIC_HTML/drraw/drraw.cgi
#!/bin/sh
exec /usr/lib/cgi-bin/drraw/drraw.cgi
$
Provided that drraw.cgi tries to locate ‘drraw.conf’ in the
current working directory first, resorting to use the “/etc”
version if that fails.
Please thus consider the patch MIME'd. (Inspired by Gitweb.)
TIA.
--
FSF associate member #7257
--- /usr/lib/cgi-bin/drraw/drraw.cgi 2010-06-10 02:41:45.0 +0700
+++ drraw.cgi 2011-06-03 23:21:51.0 +0700
@@ -37,6 +37,7 @@
use CGI qw(:standard :html3 *table *ul -no_xhtml -nosticky);
use CGI::Carp qw(fatalsToBrowser);
use Config;
+use Cwd qw (abs_path);
use Fcntl;
use File::Basename;
use File::Find;
@@ -49,7 +50,21 @@
# The configuration file is expected to be found in the same directory
# as drraw itself. You may customize this to be elsewhere.
-my $config = /etc/drraw/drraw.conf; # Untaint
+# my $config = /etc/drraw/drraw.conf; # Untaint
+sub untaint {
+my @r;
+foreach my $v (@_) {
+my %h = ($v, 1);
+push (@r, keys (%h));
+}
+## .
+wantarray () ? @r : $r[0];
+}
+our $DRRAW_CONFIG
+= untaint (abs_path (($ENV{'DRRAW_CONFIG'} || drraw.conf)));
+our $DRRAW_CONFIG_SYSTEM
+= untaint (abs_path (($ENV{'DRRAW_CONFIG_SYSTEM'}
+ || /etc/drraw/drraw.conf)));
# This needs to be manually set for stupid stupid File::Find to work
# in tainted mode.
@@ -255,7 +270,10 @@
###
# Now load the user configuration
-unless ( do $config ) {
+my $config;
+unless ((-e $DRRAW_CONFIG
+ ? do ($config = $DRRAW_CONFIG)
+ : do ($config = $DRRAW_CONFIG_SYSTEM))) {
my $err = ( $@ ne '' ) ? $@ : $!;
print
header(-status=500),
Bug#619355: #619355 lynx fails to stop on SIGTSTP (C-z)
Thomas Dickey dic...@his.com writes: This seems to work for me (trying both tcsh and bash). Can you provide more details (perhaps locale, shell/version, etc). I cannot reproduce the issue on a few of fresh Squeeze incarnations, either. However, the issue readily manifests itself on a Squeeze system which still has some Lenny packages yet to be upgraded. (Of those, only debconf is in the lynx-cur Depends: list.) So, I guess that there's some library package used by Lynx that causes the problem. I'm going to try my luck tracking it down. Thanks. (The report should probably downgraded to Severity: minor, as it seemingly may only cause an inconvenience after upgrade, and only if something went wrong, or if for some reason some packages were left not upgraded.) -- FSF associate member #7257 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#619355: lynx fails to stop on SIGTSTP (C-z)
Package: lynx-cur Version: 2.8.8dev.5-1 I start lynx as follows, and then stop it with either C-z or $ kill -TSTP as soon as it shows the page: $ lynx … [1]+ Stopped lynx $ Then, I bring it back, and stop it once again: $ fg … [1]+ Stopped lynx $ Then, I bring it back for another time: $ fg … … and it doesn't react to SIGTSTP from now on. -- FSF associate member #7257 pgpRR8PklJJ8W.pgp Description: PGP signature
Bug#472311: and Bug#585566 are the same; and both are alive and well
I believe that Bug#472311 and Bug#585566 are the same issue, actually. Indeed, most(1) reads: --cut: most(1) -- I am grateful to Robert Mills rob...@jna.com.au for re-writing the search routines to use regular expressions. --cut: most(1) -- However, I haven't found any documented way to search for a regular expression. PS. Personally, I see no compelling reason to use most(1) instead of the (much more featureful and supported) less(1). -- FSF associate member #7257 pgpMpfhrglz3o.pgp Description: PGP signature
Bug#310508: most should support POSIX option terminator (--)
John E Davis da...@space.mit.edu writes: On Sun, 11 Sep 2005 -0400, Benj. Mako Hill m...@debian.org said: Given a file named with a dash at the beginning (e.g., -.txt, ---.doc, etc.), there's no way (I found) to open such file with most directly. GNU (I think gettext-based, actually) programs have the -- option to stop switch processing; using that most could be invoked as follows: most -- ---.doc. While I can add support for --, it is much easier to use most ./-.txt instead of most -- -.txt It's a matter of convention. And it's POSIX convention for “--” to terminate the options' parsing. While it may seem of a marginal value for interactive use, it's of some real value when the program is called via exec* (). Consider that most(1) is to be called as $PAGER from a C program. To ensure that no filename is ever recognized as an option, the C program in question will have to prepend a “./” combo to /each/ of the filenames passed to $PAGER, which is a real pain to do in C. Furthermore, consider how many there are C programs which would have to be patched to support this particular “mode of operation.” Hence, I'd strongly opt for changing most(1) to conform to the world, and not vice versa. -- FSF associate member #7257 pgpVOE2cSTIZr.pgp Description: PGP signature
Bug#46660: is still there (5.0.0a-2)
Apparently, the issue manifests itself only on sufficiently big files (the buffering is obviously involved.) Consider, e. g.: $ most /usr/share/doc/libdirectfb-1.2-9/changelog.gz Should one quit without scrolling, a “Broken pipe” message will be produced (as per 5.0.0a-2.) Of the following commands, the first will result in the message on quit (once again, without scrolling), while the second won't. $ most +$((32 * 1024)) /usr/share/doc/libdirectfb-1.2-9/changelog.gz $ most +$((35 * 1024)) /usr/share/doc/libdirectfb-1.2-9/changelog.gz Still, please note that it's actually Gzip that produces the message. And I'm not that certain that it should be inhibited. -- FSF associate member #7257 pgpVn82qENN64.pgp Description: PGP signature
Bug#615890: [request-tracker-maintainers] Bug#615890: rt-mailgate(1) should support some HTTP authentication
Dominic Hargreaves d...@earth.li writes: On Tue, Mar 01, 2011 at 01:36:55AM +0600, Ivan Shmakov wrote: […] OTOH, given that the HTTP basic authentication is only a matter of calling the LWP::UserAgent's -credentials () method (as per the documentation [1]), it doesn't seem like a big deal to have it supported. I thought about forwarding this straight into the upstream bugtracker, but it might be worth you raising this on rt-users first. If it's simple as you suggest, and you have a desire for it, then it might be a case of arguing the point by submission of a suitable patch :) ACK. Actually, I've found that there's liblwp-authen-negotiate-perl, which would've the problem solved for me, given that I run Apache with mod_auth_kerb enabled anyway. Yet, that Perl module assumes the “user's” way of authentication (kinit), not the one that's apt for a service (keytab.) Hence, I may consider patching liblwp-authen-negotiate-perl instead to support krb5_get_init_creds_keytab (). (It'd still be necessary to patch rt-mailgate to specify the principal to be used, though.) Still, having some common HTTP authentication schemes supported may be a nice addition. (Though I'm not sure that anything else looks as simple as calling -credentials ().) -- FSF associate member #7257 pgpCb0k7CiF60.pgp Description: PGP signature
Bug#615890: rt-mailgate(1) should support some HTTP authentication
Package: rt3.8-clients Version: 3.8.8-7 Severity: wishlist The current version of rt-mailgate(1) relies on a specific “backdoor” to access the REST interface of RT, like: Location /rt/REST/1.0/NoAuth Order allow,deny Allow from ::1 127.0.0.0/8 Satisfy any /Location However, this configuration is insecure in at least two situations: • the RT installation is on a different host, so that the IP address may be spoofed; • the host is used for Shell accounts of some less trusted folks. OTOH, given that the HTTP basic authentication is only a matter of calling the LWP::UserAgent's -credentials () method (as per the documentation [1]), it doesn't seem like a big deal to have it supported. [1] http://search.cpan.org/~gaas/libwww-perl-5.837/lib/LWP/UserAgent.pm -- FSF associate member #7257 pgpciu6M37Db1.pgp Description: PGP signature
Bug#614948: rt-mailgate(1) doesn't support IPv6, too
One more program that is affected by this bug is rt-mailgate from rt3.8-clients: # echo test \ | (cd / su www-data -c '/usr/bin/rt-mailgate \ --debug --action=correspond \ --queue=General \ --url=https://ipv6.google.com/rt/;') /usr/bin/rt-mailgate: temp file is '/tmp/1q919srzpU' /usr/bin/rt-mailgate: connecting to https://ipv6.google.com/rt//REST/1.0/NoAuth/mail-gateway An Error Occurred = 500 Can't connect to ipv6.google.com:443 (Bad hostname 'ipv6.google.com') /usr/bin/rt-mailgate: undefined server error # A similar error is signalled should https://[::1]/rt/ (i. e., ip6-localhost) be used for an URI. Strangely enough, https://ip6-localhost/rt/ works, yet Apache's access.log shows that rt-mailgate(1) connects over IPv4 instead of IPv6. -- FSF associate member #7257 pgpLKSgVrEHyR.pgp Description: PGP signature
Bug#613730: unversioned Depends: libkafs0-heimdal may lead to trouble on upgrade
Package: heimdal-clients Version: 1.4.0~git20100726.dfsg.1-1+b1 Severity: minor Funny enough, but upgrading heimdal-clients to the one in Squeeze left /usr/bin/kinit dependent on /both/ versions of libhx509: $ ldd /usr/bin/kinit | grep libhx libhx509.so.3 = /usr/lib/libhx509.so.3 (0x7f524bae) libhx509.so.5 = /usr/lib/libhx509.so.5 (0x7f524b268000) $ Now, $ kinit produces: $ kinit kinit: symbol lookup error: /usr/lib/libhx509.so.3: undefined symbol: oid_id_pkcs3_rc2_cbc $ Apparently, it's a consequence of having an unversioned dependency on libkafs0-heimdal. Should we upgrade that one, the problem is no more. Was: ii libhx509-3-heimdal 1.2.dfsg.1-2.1Heimdal Kerberos - X50... ii libhx509-5-heimdal 1.4.0~git20100726.dfsg.1-1+b1 Heimdal Kerberos - X50... ii libkafs0-heimdal1.2.dfsg.1-2.1Heimdal Kerberos - KAF... Now: rc libhx509-3-heimdal 1.2.dfsg.1-2.1Heimdal Kerberos - X50... ii libhx509-5-heimdal 1.4.0~git20100726.dfsg.1-1+b1 Heimdal Kerberos - X50... ii libkafs0-heimdal1.4.0~git20100726.dfsg.1-1+b1 Heimdal Kerberos - KAF... PS. I guess that going through dist-upgrade would save one from the issue. -- FSF associate member #7257 pgpqYT7oamSBW.pgp Description: PGP signature
Bug#610026: openbox stalls consuming 100% CPU when pcb-gtk is started
Nico Golde n...@debian.org writes: * Dana Jansens dan...@orodu.net [2011-02-09 16:54]: On Tue, Feb 8, 2011 at 5:10 PM, Nico Golde n...@debian.org wrote: * Ivan Shmakov i...@main.uusia.org [2011-01-24 20:43]: Package: openbox Version: 3.3-2.1 Really? 3.3? That's like 2 years old. Oops! That was a fault entirely on my part. True, Ivan can you please test this with the version from at least stable? Tried 3.4.11.1-1. The issue is no more. Thanks. -- FSF associate member #7257 pgpRdyjvD5ZDY.pgp Description: PGP signature
Bug#611959: non-free documentation in the package?
Package: pdl Version: 1:2.4.7+dfsg-2 X-Debbugs-CC: per...@jach.hawaii.edu There're a few PDL manual pages that bear copyright notices (see below) that, to my understanding, limit the user's freedom to distribute the derived works. Specifically, these notices conflict DFSG [1] in that they either: • disallow “modifications and derived works” (by the means of format conversion) “to be distributed under the same terms as the license of the original software” (DFSG #3; should we assume that the license allows commercial distribution of the unaltered documentation); • restrict a “party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources” (DFSG #1; should we assume that the commercial distribution is denied altogether.) I thus believe that the distribution terms of the manual pages in question should either be changed or clarified, or the manual pages should be removed from the Debian package. [1] http://www.debian.org/social_contract#guidelines $ (for i in PDL::Objects PDL::QuickStart PDL::BadValues ; do \ printf '* %s\n' $i man $i | grep -A2 -B4 -F Commercial ; \ done) * PDL::Objects AUTHOR Copyright (C) Karl Glazebrook (k...@aaoepp.aao.gov.au), Tuomas J. Lukka, (lu...@husc.harvard.edu) and Christian Soeller (c.soel...@auckland.ac.nz) 2000. Commercial reproduction of this documentation in a different format is forbidden. * PDL::QuickStart AUTHOR Copyright (C) Karl Glazebrook (k...@aaoepp.aao.gov.au), Tuomas J. Lukka, (lu...@husc.harvard.edu) and Christian Soeller (c.soel...@auckland.ac.nz) 1997. Commercial reproduction of this documentation in a different format is forbidden. * PDL::BadValues Copyright (C) Doug Burke (djbu...@cpan.org), 2000, 2006. The per-piddle bad value support is by Heiko Klein (2006). Commercial reproduction of this documentation in a different format is forbidden. $ -- FSF associate member #7257 pgpsoCw2dxP6N.pgp Description: PGP signature
Bug#611673: probably should no longer --disable-dap-netcdf
Package: nco Version: 4.0.2-1 The nco package currently in Debian Sid is built without OPeNDAP support, which is somewhat unfortunate, since OPeNDAP is already provided by the version of NetCDF there. To enable the OPeNDAP support, I've toggled the --disable-dap-netcdf and --disable-netcdf4 switches, and also added libcurl4-gnutls-dev (since NetCDF's OPeNDAP implementation relies on it) to Build-Depends:. For the test, I've tried: $ ncks \ -d time,4,60,1 \ -d lat,286,287,1 \ -d lon,167,168,1 \ http://nomads.ncep.noaa.gov:9090/dods/gfs_hd/gfs_hd20110129/gfs_hd_00z?tmp2m \ xxx.nc (The command should retrieve a time series data on the temperature on 2 m above the ground for a particular location from the GFS data available from NOMADS.) Which just worked. TYC. NB: I haven't put much time into testing as of yet. $ interdiff \ (zcat nco_4.0.2-1.diff.gz) \ (zcat nco_4.0.2-1.0+is+0.2.diff.gz) diff -u nco-4.0.2/debian/control nco-4.0.2/debian/control --- nco-4.0.2/debian/control +++ nco-4.0.2/debian/control @@ -3,7 +3,7 @@ Priority: optional Maintainer: Charlie Zender zen...@uci.edu Uploaders: Francesco Paolo Lovergine fran...@debian.org -Build-Depends: debhelper (= 7), antlr, bison, flex, gsl-bin, libgsl0-dev, libantlr-dev, netcdf-bin, libnetcdf-dev, texinfo +Build-Depends: debhelper (= 7), antlr, bison, flex, gsl-bin, libgsl0-dev, libantlr-dev, netcdf-bin, libnetcdf-dev, libcurl4-gnutls-dev, texinfo Standards-Version: 3.8.4 Homepage: http://nco.sourceforge.net/ diff -u nco-4.0.2/debian/rules nco-4.0.2/debian/rules --- nco-4.0.2/debian/rules +++ nco-4.0.2/debian/rules @@ -53,10 +53,10 @@ --mandir=/usr/share/man \ --enable-gsl \ --enable-ncoxx \ - --disable-dap-netcdf \ + --enable-dap-netcdf \ --disable-dap-opendap \ --disable-nco_cplusplus \ - --disable-netcdf4 \ + --enable-netcdf4 \ --disable-udunits \ --disable-udunits2 \ --disable-static diff -u nco-4.0.2/debian/changelog nco-4.0.2/debian/changelog --- nco-4.0.2/debian/changelog +++ nco-4.0.2/debian/changelog @@ -1,3 +1,15 @@ +nco (4.0.2-1.0+is+0.2) 1gray-misc; urgency=low + + * Added libcurl4-gnutls-dev to Build-Depends:. + + -- Ivan Shmakov oneing...@gmail.com Mon, 31 Jan 2011 20:12:37 + + +nco (4.0.2-1.0+is+0.1) 1gray-misc; urgency=low + + * Enable both NetCDF4 and NetCDF OPeNDAP support, for future's there. + + -- Ivan Shmakov oneing...@gmail.com Mon, 31 Jan 2011 19:45:09 + + nco (4.0.2-1) unstable; urgency=low * new upstream version (netCDF4_classic behavior) $ -- FSF associate member #7257 pgptnOP8AHqY4.pgp Description: PGP signature
Bug#611346: PDL::NetCDF should support OPeNDAP, just as current NetCDF does
IS == Ivan Shmakov i...@main.uusia.org writes: […] IS The version of NetCDF currently in Debian Sid supports retrieving IS datasets via OpenDAP (see below for an example.) On the contrary, IS PDL::NetCDF doesn't: pdl my $nc = PDL::NetCDF-new (http://test.opendap.org:8080/dods/dts/test.01;); new: Cannot create netCDF file -- No such file or directory pdl IS I've traced this issue down to the PDL::NetCDF::nc_open () wrapper IS (newlines added to for readability): […] Strangely enough, but it seems that it's the OCLOGFILE=/dev/null workaround for Debian Bug#611338 that makes PDL::NetCDF-nc_open () fail. With OCLOGFILE unset or empty, it seems to work. As for the PDL::NetCDF-new () constructor, the “if (-e $file)” logic has to be amended to check for a “looks like an URI” case. (A regular expression, perhaps?) Or, alternatively, I'd vote for a completely separate new_from_uri () constructor to handle the URI objects and strings. (And then would hope for NetCDF to follow with a similar change.) -- FSF associate member #7257 pgpKgjPY5c1Yz.pgp Description: PGP signature
Bug#611338: ncdump seems to support OpenDAP URI's only up to 55 characters long
Package: netcdf-bin Version: 1:4.1.1-5 Apparently, ncdump doesn't support OpenDAP URI's of 56 characters or more in length. Consider, e. g.: $ ncdump -k http://nomads.ncep.noaa.gov:9090/dods/gfs_hd/gfs_hd20110128/gfs_hd_00z ncdump: http://nomads.ncep.noaa.gov:9090/dods/gfs_hd/gfs_hd20110128/gfs_hd_00z: NetCDF: I/O failure $ I've checked the proxy logs, and no HTTP request is recorded upon the command above. The behavior is the same should the URI be truncated to 56 characters: $ ncdump -k http://nomads.ncep.noaa.gov:9090/dods/gfs_hd/gfs_hd20110 ncdump: http://nomads.ncep.noaa.gov:9090/dods/gfs_hd/gfs_hd20110: NetCDF: I/O failure $ On the other hand, the URI's of 55 characters and less are handled differently, and the requests are being made: $ ncdump -k http://nomads.ncep.noaa.gov:9090/dods/gfs_hd/gfs_hd2011 ncdump: http://nomads.ncep.noaa.gov:9090/dods/gfs_hd/gfs_hd2011: NetCDF: DAP server error $ ncdump -k http://test.opendap.org:8080/dods/dts/test.01 64-bit offset $ -- FSF associate member #7257 pgprnfTLnI0d8.pgp Description: PGP signature
Bug#611346: PDL::NetCDF should support OpenDAP, just as current NetCDF does
Package: libpdl-netcdf-perl
Version: 4.03-1
Severity: wishlist
The version of NetCDF currently in Debian Sid supports
retrieving datasets via OpenDAP (see below for an example.) On
the contrary, PDL::NetCDF doesn't:
pdl my $nc = PDL::NetCDF-new
(http://test.opendap.org:8080/dods/dts/test.01;);
new: Cannot create netCDF file -- No such file or directory
pdl
I've traced this issue down to the PDL::NetCDF::nc_open ()
wrapper (newlines added to for readability):
pdl use PDL::NetCDF;
pdl my $ncid;
my $nc_status = PDL::NetCDF::nc_open
(http://test.opendap.org:8080/dods/dts/test.01;, 0, $ncid = -999);
printf (nc_status = %3d;\nncid = 0x%x;\n, $nc_status, $ncid);
nc_status = -68;
ncid = 0x;
pdl
The seemingly equivalent C program apparently succeeds there:
$ cat nc-example.c
#include assert.h
#include netcdf.h
#include stdio.h
int
main (int argc, char *argv[])
{
assert (argc - 1 == 1);
int ncid;
int nc_status
= nc_open (argv[1], NC_NOWRITE, ncid);
printf (nc_status = %3d;\nncid = 0x%x;\n,
nc_status, ncid);
/* . */
return 0;
}
$ gcc nc-example.c -o nc-example -lnetcdf
$ ./nc-example http://test.opendap.org:8080/dods/dts/test.01
nc_status = 0;
ncid = 0x1;
$
Of course, there's an option to use nccopy(1) here, like:
$ nccopy http://test.opendap.org:8080/dods/dts/test.01 test.nc
But it's inconvenient. (And note also Debian Bug#611338.)
PS. I guess that with OpenDAP support in PDL::NetCDF, some very
impressive demos could be made using the OpenDAP service of the
weather data available from the NOMADS project [1].
[1] http://nomads.ncep.noaa.gov/
--
FSF associate member #7257
pgptOJmxWd0na.pgp
Description: PGP signature
Bug#611338: ncdump seems to support OpenDAP URI's only up to 55 characters long
Ivan Shmakov i...@main.uusia.org writes: [BTW, I've found that the issue exists down at the nc_open () call level, so this report should probably be reassigned to libnetcdf6 and retitled appropriately.] […] On the other hand, the URI's of 55 characters and less are handled differently, and the requests are being made: […] While checking strace(1) and ltrace(1) output, I've found that the correct behavior coincides with a single DNS request, while the buggy one coincides with three. Thus, I've breakpointed GDB at recvfrom () and got the backtraces MIME'd. As far as I can see, the URL is correctly passed down to the ocfetchurl () NetCDF internal function. Unfortunately, even though libcurl3-dbg is installed, the arguments to the Curl_* functions aren't shown. Any hints? $ dpkg -l \*-dbg | grep -E ^i ii libcurl3-dbg 7.21.0-1 libcurl compiled with debug symbols ii netcdf-dbg1:4.1.1-5 debugging symbols for NetCDF $ -- FSF associate member #7257 (gdb) r Starting program: /usr/bin/ncdump -k http://nomads.ncep.noaa.gov:9090/dods/gfs_hd/gfs_hd2011 # 128/gfs_hd_00z [Thread debugging using libthread_db enabled] Breakpoint 5, 0x76934e20 in recvfrom () from /lib/libc.so.6 (gdb) bt #0 0x76934e20 in recvfrom () from /lib/libc.so.6 #1 0x75459b09 in ?? () from /lib/libresolv.so.2 #2 0x75457a75 in __libc_res_nquery () from /lib/libresolv.so.2 #3 0x75458031 in ?? () from /lib/libresolv.so.2 #4 0x7545843d in __libc_res_nsearch () from /lib/libresolv.so.2 #5 0x73d15c37 in _nss_dns_gethostbyname4_r () from /lib/libnss_dns.so.2 #6 0x7691048c in ?? () from /lib/libc.so.6 #7 0x76912782 in getaddrinfo () from /lib/libc.so.6 #8 0x77bc8af2 in Curl_getaddrinfo_ex () from /usr/lib/libcurl-gnutls.so.4 #9 0x77bc2818 in Curl_getaddrinfo () from /usr/lib/libcurl-gnutls.so.4 #10 0x77b9976c in Curl_resolv () from /usr/lib/libcurl-gnutls.so.4 #11 0x77b99897 in Curl_resolv_timeout () from /usr/lib/libcurl-gnutls.so.4 #12 0x77babcb6 in ?? () from /usr/lib/libcurl-gnutls.so.4 #13 0x77babd83 in Curl_connect () from /usr/lib/libcurl-gnutls.so.4 #14 0x77bb646f in ?? () from /usr/lib/libcurl-gnutls.so.4 #15 0x77650c61 in ocfetchurl (curl=0x665270, url=0x66e050 http://nomads.ncep.noaa.gov:9090/dods/gfs_hd/gfs_hd2011.dds;, buf=0x64f1b0, filetime=0x7fffe038) at http.c:110 #16 0x77658a75 in readpacket (curl=0x665270, url=value optimized out, packet=0x64f1b0, dxd=value optimized out, lastmodified=0x7fffb8c0) at read.c:76 #17 0x77658bf9 in readDDS (state=0x66df50, tree=value optimized out) at read.c:31 #18 0x7764fdeb in ocfetch (state=0x66df50, constraint=0x0, kind=0, rootp=0x7fffe0d8) at ocinternal.c:255 #19 0x7764ba3a in oc_fetch (conn=7, constraint=0x7fffc5c0 \001, dxdkind=0, rootp=0x7fffe158) at oc.c:593 #20 0x77655c65 in dap_oc_fetch (drno=0x648000, conn=6741840, ce=0x0, dxd=0, rootp=0x7fffe158) at daputil.c:958 #21 0x7764d51b in fetchtemplatemetadata3 (drno=0x648000) at ncdap3.c:1323 #22 0x7764e89f in nc3d_open (path=value optimized out, mode=value optimized out, ncidp=0x647f50) at ncdap3.c:199 #23 0x77612b19 in l4nc_open_file ( path=0x613040 http://nomads.ncep.noaa.gov:9090/dods/gfs_hd/gfs_hd2011;, mode=0, basepe=0, chunksizehintp=0x0, use_parallel=value optimized out, comm=value optimized out, info=0, ncidp=0x7fffe3ec) at nc4file.c:2338 #24 0x7765f008 in nc4d_open_file ( path=0x613040 http://nomads.ncep.noaa.gov:9090/dods/gfs_hd/gfs_hd2011;, mode=0, basepe=value optimized out, chunksizehintp=value optimized out, use_parallel=0, comm=0, info=0, ncidp=0x7fffe48c) at ncdap4.c:122 #25 0x776103bf in nc_open (path=0x7 Address 0x7 out of bounds, mode=-14912, ncidp=value optimized out) at nc4file.c:2400 #26 0x00405d39 in main (argc=value optimized out, argv=0x613160) at ncdump.c:2127 (gdb) (gdb) r Starting program: /usr/bin/ncdump -k http://nomads.ncep.noaa.gov:9090/dods/gfs_hd/gfs_hd2011128/gfs_hd_00z [Thread debugging using libthread_db enabled] Breakpoint 5, 0x76934e20 in recvfrom () from /lib/libc.so.6 (gdb) bt #0 0x76934e20 in recvfrom () from /lib/libc.so.6 #1 0x75459b09 in ?? () from /lib/libresolv.so.2 #2 0x75457a75 in __libc_res_nquery () from /lib/libresolv.so.2 #3 0x75458031 in ?? () from /lib/libresolv.so.2 #4 0x7545843d in __libc_res_nsearch () from /lib/libresolv.so.2 #5 0x73d15c37 in _nss_dns_gethostbyname4_r () from /lib/libnss_dns.so.2 #6 0x7691048c in ?? () from /lib/libc.so.6 #7 0x76912782 in getaddrinfo () from
Bug#611338: ncdump seems to support OpenDAP URI's only up to 55 characters long
One more observation: while trying to investigate the problem
further, I've tried to turn the logging feature of the ‘oc’
library (which is part of NetCDF) on via setting the ‘OCLOGFILE’
environment variable to point to a file. Instantly, the issue
was no more. Consider, e. g.:
$ OCLOGFILE=/dev/null \
ncdump -h
http://nomads.ncep.noaa.gov:9090/dods/gfs_hd/gfs_hd20110128/gfs_hd_00z\?tmpsfc
netcdf gfs_hd_00z {
dimensions:
lat = 361 ;
lon = 720 ;
time = 65 ;
variables:
float tmpsfc(time, lat, lon) ;
tmpsfc:_FillValue = 9.999e+20f ;
tmpsfc:missing_value = 9.999e+20f ;
tmpsfc:long_name = ** surface temperature [k] ;
// global attributes:
:title = GFS half degree (0.5x0.5) fcst starting from
00Z28jan2011, downloaded Jan 28 04:33 UTC ;
:Conventions = COARDS\n,
GrADS ;
:dataType = Grid ;
:history = Fri Jan 28 04:37:22 UTC 2011 : imported by GrADS
Data Server 2.0 ;
}
$
… A Heisenbug?
--
FSF associate member #7257
pgpaMMYFwVelt.pgp
Description: PGP signature
Bug#611200: dependencies should allow lynx-cur as an alternative to httpd
Jonathan Nieder jrnie...@gmail.com writes: Ivan Shmakov wrote: Although rarely used, Lynx implementation of CGI is actually enough for Gitweb to work (e. g., for testing purposes.) Like: […] Very interesting. In the next upload[1] the plan is for the main git package to provide gitweb (to support git instaweb better) and the gitweb package to only provide configuration and documentation: $ dpkg -L gitweb /. /etc /etc/apache2 /etc/apache2/conf.d /etc/apache2/conf.d/gitweb /etc/gitweb.conf /usr /usr/share /usr/share/doc /usr/share/doc/gitweb /usr/share/doc/gitweb/examples /usr/share/doc/gitweb/examples/index.aux-generation /usr/share/doc/gitweb/NEWS.Debian.gz /usr/share/doc/gitweb/README.Debian /usr/share/doc/gitweb/README /usr/share/doc/gitweb/changelog.Debian.gz /usr/share/doc/gitweb/changelog.gz /usr/share/doc/gitweb/copyright /usr/lib /usr/lib/cgi-bin /usr/lib/cgi-bin/gitweb.cgi - ../../share/gitweb/gitweb.cgi $ Based on your request, I am tempted to put gitweb.conf and some gitweb documentation in the main git package, too, It's my opinion that the documentation accompanying the software packaged should always go either into the package itself, or into the corresponding “-doc” package. Thus, if gitweb is to be moved to the git package, the documentation should either go into git, or git-doc. and make the role of the gitweb package backward compatibility I'd second on this. and autoconfiguration with those webservers (apache) that support it. I see nothing wrong with the main git package providing autoconfiguration for Web servers. In particular, while configuring an unsupported Web server to work with gitweb, the administrator may choose to consult the Apache configuration files. Having to install Apache to do just that may be too inconvenient. It's not uncommon to have seemingly “useless” files of such a kind. As an example, I could vaguely recall that there're (were?) a dozen or so packages that provide a /etc/logrotate.d/ file without actually mentioning logrotate in the dependencies. Consider, e. g.: $ dpkg -s dpkg | grep logrotate /etc/logrotate.d/dpkg 782ea5ae536f67ff51dc8c3e2eeb4cf9 $ dpkg -L dpkg | grep logrotate /etc/logrotate.d /etc/logrotate.d/dpkg $ Therefore, I deem the current Depends: on apache2 | httpd as somewhat too tight. Could it please be loosened? Yes, it could be loosened to a Recommends, though see above for an alternative solution. No objections on moving all the contents of the gitweb package to the main git package (provided that it will never negatively affect the dependencies of the latter), and, if necessary, git-doc, and retaining the gitweb package for compatibility / transition. Side note: have you thought about adding lynx support to git instaweb (git-instaweb.sh in the source)? It sounds to me like this could be fairly simple. If interested, g...@vger.kernel.org (no subscription required) with cc to Jakub Narebski jna...@gmail.com would presumably be the one to contact. I've never used git instaweb, but I may check it out. Thanks for the pointer. Thanks for a pointer. […] [1] - git://repo.or.cz/debian-git/jrn.git proposed-updates - http://repo.or.cz/w/debian-git/jrn.git - http://mentors.debian.net/debian/pool/main/g/git/git_1.7.4~rc3-0.0.1.dsc -- FSF associate member #7257 pgpNUAPIM3FIy.pgp Description: PGP signature
Bug#611200: dependencies should allow lynx-cur as an alternative to httpd
Package: gitweb
Version: 1.7.2.3-2.2
Although rarely used, Lynx implementation of CGI is actually
enough for Gitweb to work (e. g., for testing purposes.) Like:
$ grep -F -- CGI $LYNX_CFG
TRUSTED_LYNXCGI:/
$ ls -l
total 12
lrwxrwxrwx 1 ivan users 60 Jan 26 16:46 gitweb.cgi -
../../dist/gitweb_1.7.2.3-2.2_all/usr/lib/cgi-bin/gitweb.cgi
-rw-r--r-- 1 ivan users 531 Feb 5 2010 gitweb_config.perl
drwxr-xr-x 7 ivan users 4096 Aug 31 20:43 lhc.git
$ lynx lynxcgi://localhost${PWD}/gitweb.cgi
Do you want to execute /var/home/ivan/public/archives/git/gitweb.cgi? (y/n) y
#Untitled Git projects list Untitled Git projects feeds
git-[git-logo.png] projects /
Search:
Project Description Owner Last Change
lhc.git Unnamed repository; edit this... Ivan Shmakov 6 hours ago
summary | shortlog | log | tree
OPML TXT
^C
$
Therefore, I deem the current Depends: on apache2 | httpd as
somewhat too tight. Could it please be loosened?
--
FSF associate member #7257
pgp1vmkjYA05K.pgp
Description: PGP signature
Bug#611101: new version is available
Package: sleuthkit Version: 3.1.3-1 Severity: wishlist According to [1], there's a newer (3.2.0) version of sleuthkit available since 2010-10-28. [1] http://www.sleuthkit.org/sleuthkit/download.php -- FSF associate member #7257 pgpC75L4XKtU5.pgp Description: PGP signature
Bug#610026: openbox stalls consuming 100% CPU when pcb-gtk is started
Nico Golde n...@debian.org writes:
* Ivan Shmakov i...@main.uusia.org [2011-01-15 00:09]:
Package: openbox
Version: 3.3-2.1
Starting pcb-gtk (as of pcb-gtk 20091103-2) leads openbox to stall
while consuming 100% CPU.
not reproducible for me, neither with 20100929-2 nor with 20091103-2.
It seems that I've just found a simpler test case for the issue
(as of tk8.4 8.4.19-2):
$ date -u ; wish (printf %s\\n 'toplevel .xxx -width 1')
Mon Jan 24 18:35:47 UTC 2011
(The whole X subsystem stalls at this point. The ‘openbox’
process doesn't react on SIGTERM, but the situation resolves
after killing it with SIGKILL.)
Can you please provide an strace of openbox and pcb-gtk during that
time?
Sure, MIME'd the $ strace -tt -f output for ‘openbox’.
I guess that pcb's strace isn't of much use, since the problem
doesn't seem to be specific to pcb.
TIA.
--
FSF associate member #7257
pgpr36L3NpEXa.pgp
Description: PGP signature
11741 18:35:01.494335 read(3, 0x1c4e774, 4096) = -1 EAGAIN (Resource
temporarily unavailable)
11741 18:35:01.494388 read(3, 0x1c4e774, 4096) = -1 EAGAIN (Resource
temporarily unavailable)
11741 18:35:01.494417 read(3, 0x1c4e774, 4096) = -1 EAGAIN (Resource
temporarily unavailable)
11741 18:35:01.494463 select(4, [3], NULL, NULL, NULL) = 1 (in [3])
11741 18:35:42.073477 read(3,
\20\200\203\4Z\0\0\0\1\0\200\0\0\0\0\0\1\0\1\0\0\0\1\0P\342\3\0\0\0\0...,
4096) = 32
11741 18:35:42.073537 read(3, 0x1c4e774, 4096) = -1 EAGAIN (Resource
temporarily unavailable)
11741 18:35:42.073578 read(3, 0x1c4e774, 4096) = -1 EAGAIN (Resource
temporarily unavailable)
11741 18:35:42.073610 read(3, 0x1c4e774, 4096) = -1 EAGAIN (Resource
temporarily unavailable)
11741 18:35:42.073644 select(4, [3], NULL, NULL, NULL) = 1 (in [3])
11741 18:35:42.073970 read(3, \34\16\203\4Z\0\0\0K\1\0\0L\v
\3\0\342\3\0\0\0\0nCE\0\0\0\0\0..., 4096) = 32
11741 18:35:42.074020 read(3, 0x1c4e774, 4096) = -1 EAGAIN (Resource
temporarily unavailable)
11741 18:35:42.074055 read(3, 0x1c4e774, 4096) = -1 EAGAIN (Resource
temporarily unavailable)
11741 18:35:42.074086 read(3, 0x1c4e774, 4096) = -1 EAGAIN (Resource
temporarily unavailable)
11741 18:35:42.074120 select(4, [3], NULL, NULL, NULL) = 1 (in [3])
11741 18:35:42.119041 read(3,
\20\200\203\4Z\0\0\0\3\0\200\0\0\0\0\0\1\0\1\0\0\0\0\0P\342\3\0\0\0\0\21...,
4096) = 96
11741 18:35:42.119104 read(3, 0x1c4e774, 4096) = -1 EAGAIN (Resource
temporarily unavailable)
11741 18:35:42.119147 read(3, 0x1c4e774, 4096) = -1 EAGAIN (Resource
temporarily unavailable)
11741 18:35:42.119178 read(3, 0x1c4e774, 4096) = -1 EAGAIN (Resource
temporarily unavailable)
11741 18:35:42.119212 select(4, [3], NULL, NULL, NULL) = 1 (in [3])
11741 18:35:47.736313 read(3,
\20\200\203\4Z\0\0\0\1\0\200\0\0\0\0\0\1\0\1\0\0\0\1\0P\342\3\0\0\0\0...,
4096) = 32
11741 18:35:47.736373 read(3, 0x1c4e774, 4096) = -1 EAGAIN (Resource
temporarily unavailable)
11741 18:35:47.736413 read(3, 0x1c4e774, 4096) = -1 EAGAIN (Resource
temporarily unavailable)
11741 18:35:47.736444 read(3, 0x1c4e774, 4096) = -1 EAGAIN (Resource
temporarily unavailable)
11741 18:35:47.736478 select(4, [3], NULL, NULL, NULL) = 1 (in [3])
11741 18:35:47.736828 read(3, \34\16\203\4Z\0\0\0K\1\0\0k!
\3\0\342\3\0\0\0\0nCE\0\0\0\0\0..., 4096) = 32
11741 18:35:47.736878 read(3, 0x1c4e774, 4096) = -1 EAGAIN (Resource
temporarily unavailable)
11741 18:35:47.736914 read(3, 0x1c4e774, 4096) = -1 EAGAIN (Resource
temporarily unavailable)
11741 18:35:47.736944 read(3, 0x1c4e774, 4096) = -1 EAGAIN (Resource
temporarily unavailable)
11741 18:35:47.736977 select(4, [3], NULL, NULL, NULL) = 1 (in [3])
11741 18:35:47.779416 read(3,
\20\0\203\4Z\0\0\0\3\0\200\0\0\0\0\0\1\0\1\0\0\0\0\0\350\200\2212\377\177\0\0\20...,
4096) = 96
11741 18:35:47.779478 read(3, 0x1c4e774, 4096) = -1 EAGAIN (Resource
temporarily unavailable)
11741 18:35:47.779522 read(3, 0x1c4e774, 4096) = -1 EAGAIN (Resource
temporarily unavailable)
11741 18:35:47.779553 read(3, 0x1c4e774, 4096) = -1 EAGAIN (Resource
temporarily unavailable)
11741 18:35:47.779588 select(4, [3], NULL, NULL, NULL) = 1 (in [3])
11741 18:35:47.779934 read(3,
\24\342\203\4Z\0\0\0\4\0\200\0\0\0\0\0\0\0\0\0\0\0\0\0 \0\0\0\0\0\0\0...,
4096) = 32
11741 18:35:47.779984 read(3, 0x1c4e774, 4096) = -1 EAGAIN (Resource
temporarily unavailable)
11741 18:35:47.780026 select(4, [3], [3], NULL, NULL) = 1 (out [3])
11741 18:35:47.780065 writev(3, [{$\0\1\0+\0\1\0..., 8}], 1) = 8
11741 18:35:47.780105 select(4, [3], [], NULL, NULL) = 1 (in [3])
11741 18:35:47.780175 read(3,
\1\0\205\4\0\0\0\0\r\0@\0\0\0\0\0H3\7\0\0\0\0\0p\205\2212\377\177\0\0...,
4096) = 32
11741 18:35:47.780245 read(3, 0x1c4e774, 4096) = -1 EAGAIN (Resource
temporarily unavailable)
11741 18:35:47.780277 read(3, 0x1c4e774, 4096) = -1 EAGAIN (Resource
temporarily unavailable)
11741 18:35:47.780316 read(3, 0x1c4e774, 4096) = -1 EAGAIN (Resource
temporarily
Bug#610026: openbox stalls consuming 100% CPU when pcb-gtk is started
Package: openbox Version: 3.3-2.1 Starting pcb-gtk (as of pcb-gtk 20091103-2) leads openbox to stall while consuming 100% CPU. As per my observations using twm (1:1.0.1-4), pcb-gtk initially opens a very small (possibly 0x0) main window, which is then extended as necessary after all its other windows are mapped. -- FSF associate member #7257 pgpVGWsEKyDaS.pgp Description: PGP signature
Bug#609816: package's Homepage: contains a misleading URI
Package: jigdo-file
Version: 0.7.3-3
The package's header reads:
Homepage: http://atterer.net/jigdo/
However, this URI currently points to a “domain for sale” page.
As per Wikipedia [1], the project's home page resides at:
http://atterer.org/jigdo/
A possible patch is MIME'd.
[1] http://en.wikipedia.org/wiki/Jigdo
--
FSF associate member #7257
--- jigdo-0.7.3/debian/control
+++ jigdo-0.7.3/debian/control
@@ -9,7 +9,7 @@
Architecture: any
Depends: wget, ${shlibs:Depends}
Conflicts: jigdo ( 0.6.9)
-Homepage: http://atterer.net/jigdo/
+Homepage: http://atterer.org/jigdo/
Description: Download Debian CD images from any Debian mirror
Using the jigdo-lite script contained in this package, you can use
your nearest regular Debian mirror to download Debian CD images,
pgpxXrWMZ6zwD.pgp
Description: PGP signature
Bug#584699: [Pkg-openmpi-maintainers] Bug#584699: programs freeze on first MPI op. when run on multihomed IPv6 hosts
Ivan Shmakov i...@main.uusia.org writes: Manuel Prinz man...@debian.org writes: thanks for the report! I also took this upstream, but unfortunately neither upstream nor I can reproduce the bug since we do not have multi-homed IPv6 hosts available for testing. If you could help us testing and/or provide us with further information this would be really great! I CC'ed Jeff (upstream) since I'm not exactly sure what he needs. When working with the package recently, I've stumbled upon what may be another manifestation of the same bug. Now, I suspect that it's not IPv6 addresses by itself that trigger the problem, but rather the length of their respective string representations. […] Apparently, I was confused over the output like (as enabled by the ‘--mca btl_base_verbose 30 option’): [n1-4.ncu.am-1.org:12674] btl: tcp: attempting to connect() to address 192.168.57.85 on port 516 Note that port 516 (be it TCP or UDP) is privileged and obviously cannot be used by a program run unprivileged. Now, I see that it's not truncation, but a byte order problem — it's the port 1026 (#x402) that's meant here, not 516 (#x204.) Which is most probably a consequence of a missing (or wrongly placed) ntohs () or htons () call. Which, however, I assume to be a completely different issue. -- FSF associate member #7257 pgp5OMA2SgZQy.pgp Description: PGP signature
Bug#584699: [Pkg-openmpi-maintainers] Bug#584699: programs freeze on first MPI op. when run on multihomed IPv6 hosts
Manuel Prinz man...@debian.org writes:
thanks for the report! I also took this upstream, but unfortunately
neither upstream nor I can reproduce the bug since we do not have
multi-homed IPv6 hosts available for testing.
“Fortunately,” it appears that you don't need one, as the
problem apparently arises on multi-IPv4-homed hosts as well.
Trying to work-around the problem, I've tried both the
--mca oob_tcp_disable_family 6 \
--mca btl_tcp_disable_family 6 \
options' combination, and building the package without the IPv6
support:
--- openmpi-1.4.2/debian/rules
+++ openmpi-1.4.2/debian/rules
@@ -57,6 +57,7 @@
--includedir=\$${prefix}/lib/openmpi/include\
--with-devel-headers \
--enable-heterogeneous \
+ --disable-ipv6 \
$(TORQUE)
# Thread support disabled because it's broken, see bug #435581
To my surprise, it didn't help!
Then, however, I observed that the system is IPv4-multihomed
just as well:
$ ip -4
…
2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state
UNKNOWN qlen 1000
inet 192.168.57.XX/24 scope global eth0
inet 192.168.57.ZZ/24 scope global eth0
…
$
As soon as I have removed one of the addresses (with
# ip addr del), the problem was gone. (As long as IPv6 is
turned off, — I cannot drop the extra IPv6 addresses on that
host without running into issues.)
To reproduce the problem, one can try, e. g. (assuming A.B.C.D
is an unused address in the network, MASK is the netmask, and
ethN is the network interface):
root# ip addr add A.B.C.D/MASK dev ethN
root#
$ mkdir -- test
$ cd test/
$ cp -- /usr/share/doc/hpcc/examples/_hpccinf.txt hpccinf.txt
$ rm -f -- hpccoutf.txt
$ mpirun.openmpi \
--mca btl_base_verbose 30 \
--mca oob_tcp_debug 1 \
--mca oob_tcp_disable_family 6 \
--mca btl_tcp_disable_family 6 \
hpcc \
/dev/null
While normally this would create ‘hpccoutf.txt’ almost
immediately, the problem being discussed will make ‘hpcc’ stuck
before it'll try to open (create) the file.
Removing the extra IP addresses should eliminate the problem.
[…]
--
Long Happy Life.
pgpPJsl1uKvCm.pgp
Description: PGP signature
Bug#584699: [Pkg-openmpi-maintainers] Bug#584699: programs freeze on first MPI op. when run on multihomed IPv6 hosts
Manuel Prinz man...@debian.org writes: thanks for the report! I also took this upstream, but unfortunately neither upstream nor I can reproduce the bug since we do not have multi-homed IPv6 hosts available for testing. If you could help us testing and/or provide us with further information this would be really great! I CC'ed Jeff (upstream) since I'm not exactly sure what he needs. When working with the package recently, I've stumbled upon what may be another manifestation of the same bug. Now, I suspect that it's not IPv6 addresses by itself that trigger the problem, but rather the length of their respective string representations. Actually, I guess that there's some static buffer involved, which is long enough to hold something like tcp://192.168.144.120:54321 (and tcp6://2002:bc87::1:54321), but truncates tcp6://2002:bc87:e7e5:2444:272:eff:fe0f:e02f:43210 at the 48'th character or so. Unfortunately, I was unable to find the relevant part of the code to check it myself. (Hopefully, I'd be able to gather some debugging output tomorrow.) […] -- FSF associate member #7257 pgpKstX6NQsF7.pgp Description: PGP signature
Bug#604004: package Description: doesn't mention XSL-FO
Package: docbook-xsl-ns Version: 1.75.2+dfsg-5 Severity: wishlist It's common to abbreviate “XSL Formatting Objects” as XSL-FO: both English Wikipedia uses this term (say, [1]), and the XSL 1.1 specification [2] makes a reference to it. Yet, while DocBook 5 XSL certainly allows one to produce XSL-FO, the straightforward ‘$ apt-cache search xsl-fo ’ search has no mention of the package. Indeed, the description reads: The stylesheets provide XSLT transformations for (X)HTML, WordML, HTML Help, JavaHelp, Man page (nroff), Website, Eclipse Platform Help file and Formatting Object (FO) output. The latter can be further processed to a number of print formats using FOP or TeX-based tools. Therefore, I suggest the following change: The stylesheets provide XSLT transformations for (X)HTML, WordML, HTML Help, - JavaHelp, Man page (nroff), Website, Eclipse Platform Help file and Formatting - Object (FO) output. The latter can be further processed to a number of print - formats using FOP or TeX-based tools. + JavaHelp, Man page (nroff), Website, Eclipse Platform Help file and XSL + Formatting Objects (XSL-FO) output. The latter can be further processed to a + number of print formats using FOP or TeX-based tools. [1] http://en.wikipedia.org/wiki/XSL_Formatting_Objects [2] http://www.w3.org/TR/xsl11/ -- FSF associate member #7257 pgpsnivMwFzxf.pgp Description: PGP signature
Bug#604008: package Description: doesn't mention neither XSL-FO, nor RTF, etc.
Package: fop Version: 1:1.0.dfsg-3 Severity: wishlist It's common to abbreviate “XSL Formatting Objects” as XSL-FO: both English Wikipedia uses this term (say, [1]), and the XSL 1.1 specification [2] makes a reference to it. Yet, while FOP may consume XSL-FO, and produce a wide variety of presentations, the straightforward ‘$ apt-cache search xsl-fo ’ search results in no mention of the package (neither the search for, say, “rtf” results in one.) Indeed, the description reads: Description: XML to PDF Translator FOP is a print formatter driven by XSL formatting objects. It is a Java application that reads a formatting object tree and then turns it into a PDF document. The formatting object tree can be in the form of an XML document (output by an XSLT engine like xalan) or can be passed in memory as a DOM Document or (in the case of xalan) SAX events. Therefore, I suggest the description to be changed as follows: Description: FOP is an XML formatter driven by XSL Formatting Objects (XSL-FO.) FOP is a Java application that reads a formatting object tree and then turns it into a wide variety of output presentations (including AFP, PCL, PDF, PNG, PostScript, RTF, TIFF, and plain text), or displays the result on-screen. . The formatting object tree can be in the form of an XML document (output by an XSLT engine like xalan) or can be passed in memory as a DOM Document or (in the case of xalan) SAX events. [1] http://en.wikipedia.org/wiki/XSL_Formatting_Objects [2] http://www.w3.org/TR/xsl11/ -- FSF associate member #7257 pgpCzFiskF4tL.pgp Description: PGP signature
Bug#604004: package Description: doesn't mention XSL-FO
The description also has no explicit mention of XHTML: The stylesheets provide XSLT transformations for (X)HTML, WordML, HTML Help, Arguably, it would be better to explicitly mention “XHTML, HTML”, so that the package would be among the “$ apt-cache search xhtml” results. -- FSF associate member #7257 pgpX0dY1CcDhI.pgp Description: PGP signature
Bug#603606: RFP: librdf-query-perl -- SPARQL/RDQL implementation in Perl
Package: wnpp Severity: wishlist RDF::Query [1] is a SPARQL implementation in Perl, aiming at SPARQL 1.1 [2] (currently a W3C draft) support. Apparently, most of the SPARQL 1.1 implementations available today are Java-based. It would be nice would Debian choose to provide a less cumbersome way to Semantic Web. (Note that it relies on RDF::Trine [3].) [1] http://search.cpan.org/dist/RDF-Query/ [2] http://www.w3.org/TR/sparql11-query/ [3] http://search.cpan.org/dist/RDF-Trine/ -- FSF associate member #7257 pgpmYD2YA9H68.pgp Description: PGP signature
Bug#601374: 1^^xsd:boolean isn't true
Source: rasqal
Version: 1.0.10-3
Please consider the following RDF graph representations:
$ rdfproc -s sqlite +sparql-2010-10-25.sqlite \
serialize ntriples
uuid:d9054928-e048-11df-a0c0-4040a5e6bfa3#subject
uuid:d9054928-e048-11df-a0c0-4040a5e6bfa3#predicate
true^^http://www.w3.org/2001/XMLSchema#boolean .
$ rdfproc -s sqlite +sparql-2010-10-25.sqlite.~5~ \
serialize ntriples
uuid:d9054928-e048-11df-a0c0-4040a5e6bfa3#subject
uuid:d9054928-e048-11df-a0c0-4040a5e6bfa3#predicate
1^^http://www.w3.org/2001/XMLSchema#boolean .
$
Following [1, 2], my understanding is that these are
representations of essentially the same graph. Thus, I'd expect
that the following SPARQL query to produce identical results for
both of the storages, contrary to what actually happens:
$ rdfproc -s sqlite +sparql-2010-10-25.sqlite \
query sparql - 'SELECT ?s ?p WHERE { ?s ?p true . }'
rdfproc: Query returned bindings results:
result: [s=[uuid:d9054928-e048-11df-a0c0-4040a5e6bfa3#subject],
p=[uuid:d9054928-e048-11df-a0c0-4040a5e6bfa3#predicate]]
rdfproc: Query returned 1 results
$ rdfproc -s sqlite +sparql-2010-10-25.sqlite.~5~ \
query sparql - 'SELECT ?s ?p WHERE { ?s ?p true . }'
rdfproc: Query returned bindings results:
rdfproc: Query returned 0 results
$
[1] http://www.w3.org/TR/xmlschema11-2/#boolean
[2] http://www.w3.org/TR/xmlschema11-2/#f-booleanLexmap
--
FSF associate member #7257
pgpLr6t14Yng7.pgp
Description: PGP signature
Bug#600728: ncgen fails to pass more than 2 ^{18} (or so) elements to a variable
Package: 1:4.1.1-5
Version: netcdf-bin
$ cat xxx.cdl
netcdf xxx {
dimensions:
count = 524288;
variables:
integer foo(count);
data:
foo = 1, 2, 3, 4, [and so on…], 524286, 524287, 524288;
}
$
Given a CDL file like one shown above (as generated by the Shell
script MIME'd), ncgen(1) fails to properly pass all the values
to the variable in the NetCDF file created:
$ ncgen -o xxx.nc xxx.nc.text
$ ncdump xxx.nc
netcdf xxx {
dimensions:
count = 524288 ;
variables:
int foo(count) ;
data:
foo = 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20,
[27834 more lines…]
262138, 262139, 262140, 262141, 262142, 262143, 262144, _, _, _, _, _, _,
[10922 more lines…]
_, _, _, _, _, _, _, _, _, _ ;
}
$
(Please note that there's no diagnostics which may suggest that
anything has gone wrong.)
To me, it would seem like a fixed buffer problem, though I
didn't look at the code as of yet.
--
FSF associate member #7257
#!/bin/bash
: ${count:=$((512 * 1024))}
cat EOF
netcdf xxx {
dimensions:
count = ${count};
variables:
integer foo(count);
data:
foo = 1$(seq -f , %.0f 2 $count | tr -d \\n);
}
EOF
pgpmiTTPRDbaG.pgp
Description: PGP signature
Bug#599312: Libgcrypt warning: missing initialization
Package: metalink Version: 0.3.6-1 I was somewhat surprised to find the following in one of my syslog logs. Oct 6 22:30:25 briareus metalink: Libgcrypt warning: missing initialization - please fix the application -- FSF associate member #7257 pgpaBwijmEadk.pgp Description: PGP signature
Bug#596503: rdfproc ... serialize atom catches SIGSEGV
Package: redland-utils Version: 1.0.10-3 Please consider the following example. $ rdfproc -s sqlite test.sqlite \ parse 'http://www.atomenabled.org/atom.xml' rss-tag-soup rdfproc: Parsing URI http://www.atomenabled.org/atom.xml with rss-tag-soup parser $ rdfproc -s sqlite test.sqlite \ serialize atom \ atom.rdf ; echo $? bash: [9576: 2 (255)] tcsetattr: Invalid argument 139 $ -- FSF associate member #7257. SFD in Barnaul: http://sfd.am-1.org/ pgpWPqjr6rbxJ.pgp Description: PGP signature
Bug#595898: downgrade Depends: tsocks to Recommends:
Package: tor Version: 0.2.1.26-1 Severity: wishlist Please consider downgrading the ‘tsocks’ dependency to Recommends:. IIUC, ‘tsocks’ is only required to use the Tor services at the same host as the Tor node itself. Apparently, it's not necessary at all to operate a Tor node, providing SOCKS services to the other hosts on the network. -- FSF associate member #7257 pgpes7wwn7LJ4.pgp Description: PGP signature
Bug#584702: [Pkg-openmpi-maintainers] Bug#584702: tcp6:// URI's don't follow RFC 3986
MP == Manuel Prinz man...@debian.org writes: MP could you please provide feedback if the problem still exists? MP Neither upstream nor I do have a working IPv6 setup, so we cannot MP test if the patch really fixes the problem. I guess that there's still IPv6 loopback address (::1; check, e. g., $ ping6 ::1), but I'm not sure whether it would be of any use for testing. MP You're help would be very much appreciated! MP In case you do not have time to do the testing, please let us know MP so we can get back to you later again. If I do not get an email MP from you in next two weeks, I consider this problem solved and MP close the bug. Hopefully, I will be able to get to the systems we had OpenMPI installed before the weekend. (And if not, I'll try to think something up.) -- FSF associate member #7257 pgpd32G5ooexE.pgp Description: PGP signature
Bug#594131: several deficiencies in the command line arguments handling
Package: metalink
Version: 0.3.6-1
The current implementation of the command line arguments
handling in metalink(1) has several deficiencies:
• a single dash (‘-’) is not recognized as synonymous to
standard input, thus requiring a workaround (like using
‘/dev/stdin’ instead); compare:
$ metalink --nomirrors --alldigests /dev/stdin /dev/null /dev/null
Hashing '/dev/stdin' ...
$ metalink --nomirrors --alldigests - /dev/null /dev/null
Unable to open '-'
$
• the POSIX standard option terminator (‘--’) is not handled
properly in the presence of the single dash argument; compare:
$ metalink --nomirrors --alldigests -- - /dev/null /dev/null
Unable to open '--'
Unable to open '-'
$ metalink --nomirrors --alldigests -- /dev/stdin /dev/null /dev/null
Hashing '/dev/stdin' ...
$
Also, it would be nice if the base URI's could be specified via
command line options (instead of the standard input), as it
would enable one to, say:
$ find foo/ -type f \
-exec metalink --alldigests --base=http://example.com/ -- {} +
Currently, it's possible to use, e. g.:
$ printf %s\\n http://example.com/ \
| find foo/ -type f \
-exec metalink --alldigests -- {} +
instead, but it only works as long as all the arguments fit into
a single exec* () call. (Shouldn't be a problem on GNU/Hurd,
but may be one on GNU/Linux.)
--
FSF associate member #7257
pgpsVbdYXQ4MH.pgp
Description: PGP signature
Bug#594134: metastore(1) -f option's argument isn't handled properly
Package: metastore Version: 1+20080623+debian-1 Apparently, the command's ‘-f’ option's argument isn't handled properly: $ command time metastore -sf FILE -- . Failed to open (null): Bad address Command exited with non-zero status 1 … $ command time metastore -s -f FILE -- . Failed to open (null): Bad address Command exited with non-zero status 1 … $ While the (should be) synonymous ‘--file’ long option has no such problem: $ command time metastore -s --file FILE -- . 0.00user 0.01system 0:00.02elapsed 50%CPU (0avgtext+0avgdata 4352maxresident)k 0inputs+136outputs (0major+331minor)pagefaults 0swaps $ command time metastore -s --file=FILE -- . 0.00user 0.01system 0:00.02elapsed 50%CPU (0avgtext+0avgdata 4368maxresident)k 0inputs+136outputs (0major+332minor)pagefaults 0swaps $ -- FSF associate member #7257 pgpW4qA0qENgP.pgp Description: PGP signature
Bug#587994: new version's available
Source: swi-prolog Version: 5.8.2-2 Severity: wishlist Please consider packaging the version released this week. --cut: news:1277758011.27957.0.ca...@ct -- Date: Mon, 28 Jun 2010 22:46:51 +0200 Hi, I've uploaded SWI-Prolog 5.11.2. Lots of changes without a clear line. There are some important kernel fixes (some crash-fixes and a memory leak) and a lot of additions and fixes to the RDF infrastructure. --cut: news:1277758011.27957.0.ca...@ct -- -- FSF associate member #7257 pgpmeCrGMwvXT.pgp Description: PGP signature
Bug#584699: programs freeze on first MPI op. when run on multihomed IPv6 hosts
Source: openmpi Version: 1.4.1-1 Programs run under mpirun(1) freeze on first MPI operation when multiple addresses per interface are involved. The configuration was roughly as follows: $ ip addr … 2: eth0: … … inet6 2001:db8::2XX:::/64 scope global dynamic … inet6 2001:db8::17a:170:1:4/64 scope global valid_lft forever preferred_lft forever … $ (I. e., one address was configured in interfaces(5), while the other was thanks to the stateless IPv6 autoconfiguration.) The mpirun(1) was invoked like: $ mpirun -nperboard 4 -H node1…,node2…,node3… hpcc… /dev/null which resulted in orted(1) being spawned on the nodes, with both of the IPv6 addresses in the tcp6:// URI's. The payload processes were consuming 100% CPU each, but no progress was made. (While we've tried to diagnose the problem, it was observed that the nodes have actually formed two disjoint sets, with the nodes of a single set being able to participate in a parallel computation spawned at any node, but all the attempts to spawn a task using the nodes from different sets have resulted in the behavior described above; apparently, the sets were formed with some dependence on the MAC address.) The behavior was 100%-reproducible. Switching the stateless configuration off on the nodes with sysctl(8) and removing the extra IP have fixed the problem. # sysctl -w net.ipv6.conf.eth0.accept_ra=0 # ip addr del 2001:db8::2XX:::/64 dev eth0 # -- FSF associate member #7257 pgphbQbPmTkFL.pgp Description: PGP signature
Bug#584702: tcp6:// URI's don't follow RFC 3986
Package: openmpi-bin Version: 1.4.1-1 RFC 3986 reads: --cut-- A host identified by an Internet Protocol literal address, version 6 [RFC3513] or later, is distinguished by enclosing the IP literal within square brackets ([ and ]). --cut-- However, mpirun(1) results in orted(1) being passed URI's like: tcp6://2001:DB8::1:54321/ (i. e., without the brackets.) -- FSF associate member #7257 pgp7OkrlYXybQ.pgp Description: PGP signature
Bug#561718: Can confirm Bug#561718: subprocess installed post-installation script
Tobias Klauser tklau...@distanz.ch writes: [...] I can reproduce this bug here: | Setting up nfs-common (1:1.2.1-3) ... | insserv: Service portmap has to be enabled to start service nfs-common | insserv: exiting now! | update-rc.d: error: insserv rejected the script header | dpkg: error processing nfs-common (--configure): | subprocess installed post-installation script returned error exit status 1 | Errors were encountered while processing: | nfs-common | E: Sub-process /usr/bin/dpkg returned an error code (1) The message suggests that the portmap initscript is not enabled at the time of the installation (which is the case here on my netbook, I don't want to have it started at boot by default). And indeed after reactivating portmap using 'insserv /etc/init.d/portmap' the nfs-common installation was successful. I have observed a similar issue when trying to build a Debian Live image with nfs-common and rpcbind. Obviously, in this particular case /no/ service should be started during the installation of the packages. # lh build [...] Setting up rpcbind (0.2.0-4) ... update-rc.d: warning: rpcbind start runlevel arguments (S) do not match LSB Default-Start values (S 2 3 4 5) All runlevel operations denied by policy Setting up nfs-common (1:1.2.1-3) ... Creating config file /etc/idmapd.conf with new version Creating config file /etc/default/nfs-common with new version insserv: Service portmap has to be enabled to start service nfs-common insserv: exiting now! update-rc.d: error: insserv rejected the script header dpkg: error processing nfs-common (--configure): subprocess installed post-installation script returned error exit status 1 [...] Eventually, the build fails with: [...] Errors were encountered while processing: nfs-common E: Sub-process /usr/bin/dpkg returned an error code (1) P: Begin unmounting filesystems... Command exited with non-zero status 123 # -- FSF associate member #7257 pgpYPsZEzJq4Z.pgp Description: PGP signature
Bug#575029: collectd2html.pl should produce XHTML
Sebastian Harl tok...@debian.org writes: Ivan Shmakov wrote: As the support for XHTML becomes increasingly common, it may make sense to implement XHTML output in collectd2html.pl. [...] To cut a long story short: would you be willing to provide a patch for that? I'd be willing, but most likely unable to. Not during the next three weeks or so, at least. If not, I'd be forwarding the issue upstream, but I would not expect much feedback. Patches are always very welcome (upstream), though. ACK. FWIW, the whole issue is, as it seems to me, mostly about lowercasing the tags and checking the output with W3C Validator (and fixing the issues reported.) -- FSF associate member #7257 pgpWP6BNCdtnc.pgp Description: PGP signature
Bug#575029: collectd2html.pl should produce XHTML
Sebastian Harl tok...@debian.org writes: [...] PS: Btw., just out of curiosity: Why do you use collectd2html rather than, e.g., collection3? Mostly because of lacking enough spare time to spend on learning some other tool. Thanks for the pointer, BTW. How do you trigger the rebuild of the contents? Roughly speaking, I rebuild the contents at some time intervals, sometimes as large as week. -- FSF associate member #7257 pgpnPKqp9Ggv2.pgp Description: PGP signature
Bug#368604: [PATCH] Better safety check for file names in BitTornado
VN == Vladislav Naumov vn...@vnaum.com writes:
VN On a second thought, checking filenames for safety with a regular
VN expression doesn't work very well:
[...]
VN Of course, user can download new .bashrc in his homedir and break
VN it. He could do this with wget as well: that's not a problem of a
VN software, it's just user doing stupid things (downloading something
VN in a homedir).
FWIW, I second the opinion.
Note also that the unpatched version disallows both ‘/’ and ‘\’
in the file names, which prevents distributing whole directories
when using BitTornado, and it doesn't feel sensible to me. The
patch seems to resolve the problem.
VN Patch attached.
At a superficial scan, a slightly different patch is needed as
of bittornado 0.3.18-8 (note the last hunk.) I haven't tested
it thoroughly, though.
--
FSF associate member #7257
--- BitTornado/BT1/btformats.py.~1~ 2004-05-25 23:00:58.0 +0700
+++ BitTornado/BT1/btformats.py 2010-03-22 20:37:58.0 +0600
@@ -3,11 +3,14 @@
from types import StringType, LongType, IntType, ListType, DictType
from re import compile
-
-reg = compile(r'^[^/\\.~][^/\\]*$')
+from os.path import abspath
ints = (LongType, IntType)
+def is_safe(name):
+# check if name is within current directory
+return abspath(name).startswith(abspath('.'))
+
def check_info(info):
if type(info) != DictType:
raise ValueError, 'bad metainfo - not a dictionary'
@@ -20,7 +23,7 @@
name = info.get('name')
if type(name) != StringType:
raise ValueError, 'bad metainfo - bad name'
-if not reg.match(name):
+if not is_safe(name):
raise ValueError, 'name %s disallowed for security reasons' % name
if info.has_key('files') == info.has_key('length'):
raise ValueError, 'single/multiple file mix'
@@ -44,7 +47,7 @@
for p in path:
if type(p) != StringType:
raise ValueError, 'bad metainfo - bad path dir'
-if not reg.match(p):
+if not is_safe(p):
raise ValueError, 'path %s disallowed for security reasons' % p
for i in xrange(len(files)):
for j in xrange(i):
pgpdrHMaDew0F.pgp
Description: PGP signature
Bug#575029: collectd2html.pl should produce XHTML
Package: collectd-core Version: 4.9.1-2 Severity: wishlist As the support for XHTML becomes increasingly common, it may make sense to implement XHTML output in collectd2html.pl. Some of the benefits are: * easier post-processing with XML-capable tools; * inline SVG [1], thus: - saving both disk space and bandwidth (multiple GET requests vs. a single one)… - … and some gratuitous object / instances as well, which certain software, such as xul-ext-noscript, consider dangerous for a reason. There's yet another way to avoid extra GET thanks to the data: scheme, as per RFC 2397 [2], but it doesn't allow to get rid of the ‘object /’s. [1] http://wiki.svg.org/index.php?title=Inline_SVG [2] http://tools.ietf.org/rfc/rfc2397 -- FSF associate member #7257 pgpiLYBv7T0g8.pgp Description: PGP signature
Bug#574860: bttrack apparently chokes on requests from IPv6 peers
Package: bittornado
Version: 0.3.18-8
Apparently, the problem described in [1] also exists with the
Debian Lenny bittornado package.
Namely, when IPv6 peers connect to a bttrack(1) instance, a
traceback is written to LOG (see the attached example), with no
peer being able to discover the other.
There's a patch [1] (also attached) that apparently fixes the
problem. The bttrack(1) instance (both before and after
patching) was started like:
$ (cd DIR bttrack --compact_reqd 0 \
--dfile DFILE --port PORT --ipv6_enabled 1 --ipv6_binds_v4 1 \
/dev/null LOG 21)
The peers were:
$ btdownloadcurses --ipv6_enabled 1 \
TORRENT-FILE
[1] http://www.cs.helsinki.fi/u/sklvarjo/torrent.html
--
FSF associate member #7257
Traceback (most recent call last):
File /var/lib/python-support/python2.5/BitTornado/RawServer.py, line 144,
in listen_forever
self.sockethandler.handle_events(events)
File /var/lib/python-support/python2.5/BitTornado/SocketHandler.py, line
319, in handle_events
s.handler.data_came_in(s, data)
File /var/lib/python-support/python2.5/BitTornado/HTTPHandler.py, line 155,
in data_came_in
if not c.data_came_in(data) and not c.closed:
File /var/lib/python-support/python2.5/BitTornado/HTTPHandler.py, line 46,
in data_came_in
self.next_func = self.next_func(val)
File /var/lib/python-support/python2.5/BitTornado/HTTPHandler.py, line 78,
in read_header
r = self.handler.getfunc(self, self.path, self.headers)
File /var/lib/python-support/python2.5/BitTornado/BT1/track.py, line 951,
in get
return_type, rsize, params('supportcrypto'))
File /var/lib/python-support/python2.5/BitTornado/BT1/track.py, line 782,
in peerlist
cache = self.cached.setdefault(infohash,[None,None,None])[return_type]
IndexError: list index out of range
--- track.py.orig 2009-07-23 13:51:24.0 +0300
+++ track.py2009-07-23 13:48:51.0 +0300
@@ -773,7 +773,10 @@
data['peers'] = []
return data
l_get_size = int(float(rsize)*(len_l)/(len_l+len_s))
-cache = self.cached.setdefault(infohash,[None,None,None])[return_type]
+if self.config['compact_reqd']:
+cache = self.cached.setdefault(infohash,[None,None,None])[return_type]
+else:
+cache = self.cached.setdefault(infohash,[None,None,None,None,None])[return_type]
if cache and ( not cache[1]
or (is_seed and len(cache[1]) rsize)
or len(cache[1]) l_get_size
pgpSm2Od5DD3u.pgp
Description: PGP signature
Bug#568502: LVM support should be added
Package: live-initramfs Version: 1.157.4-2 Severity: wishlist Please add LVM support in live-initramfs, so that it will become possible to host Live filesystem images on LVM logical volumes. To do that, two changes are to be made: * the local-top/lvm2 script (of initramfs-tools) should somehow be called earlier, most probably as part of the live-premount/ sequence; * the script should also consider $LIVE_MEDIA, like: activate_vg $ROOT + activate_vg $LIVE_MEDIA activate_vg $resume FWIW, copying the script's contents into /scripts/live-premount/zz_lvm2, making the change above and recreating the image (with $ fakeroot... cpio --quiet --dereference -o -H newc | gzip -9c ...) have allowed me to create a bootable Debian Live system with the Live image residing on a logical volume. -- FSF associate member #7257 pgpgot6hVbkUD.pgp Description: PGP signature
Bug#555411: inconsistent underscores in Fortran interface functions names
BTW, I was able to build SDP Toolkit 5.2.16v1.00, M-API 2.3.4 (10 Mar 2003) and then MODIS Cloud Mask (MOD35_L2) and Atmospheric Profiles (MOD07_L2) on top of the hdf-eos4 and hdf-eos5 packages modified as suggested. (Albeit not without some hacking all along the way.) So far, the programs seem to run fine. Now, I'm experimenting with MODIS L2 Land Surface Reflectance (i. e., ``no atmosphere'' reflectance.) -- FSF associate member #7257 pgpVHuU5tz8oz.pgp Description: PGP signature
Bug#557322: --exclude='ing essential packages
Package: debootstrap
Version: 1.0.10lenny1
Severity: minor
debootstrap(8) reads:
--cut--
--exclude=alpha,beta
Comma separated list of packages which will be removed from
download and extract lists. WARNING: you can and probably will
exclude essential packages, be careful using this option.
--cut--
However, it seems that it doesn't allow, say, initscripts
co. to be excluded:
# debootstrap --verbose --variant=minbase \
--exclude=initscripts,sysv{-rc,init{,-utils}},login,mount \
--include=bind9-host,bzip2,gawk,less,psmisc,tree,zip \
--keep-debootstrap-dir \
--print-debs \
lenny \
/tmp/$(date +%s)/ \
file:/com/waterlily.public/debian/
I: Retrieving Release
I: Retrieving Packages
I: Validating Packages
I: Resolving dependencies of required packages...
I: Resolving dependencies of base packages...
I: Found additional base dependencies: debian-archive-keyring gnupg gpgv
libbind9-40 libbz2-1.0 libcap2 libdns45 libisc45 libisccc40 libisccfg40
libkeyutils1 libkrb53 liblwres40 libreadline5 libssl0.9.8 libusb-0.1-4 libxml2
readline-common
base-files base-passwd bash bsdutils coreutils debconf debconf-i18n debianutils
diff dpkg e2fslibs e2fsprogs findutils gcc-4.2-base gcc-4.3-base grep gzip
hostname initscripts libacl1 libattr1 libblkid1 libc6 libcomerr2 libdb4.6
libdevmapper1.02.1 libgcc1 liblocale-gettext-perl libncurses5 libpam-modules
libpam-runtime libpam0g libselinux1 libsepol1 libslang2 libss2 libstdc++6
libtext-charwidth-perl libtext-iconv-perl libtext-wrapi18n-perl libuuid1 login
lsb-base lzma makedev mawk mktemp mount ncurses-base ncurses-bin passwd
perl-base procps sed sysv-rc sysvinit sysvinit-utils tar tzdata util-linux
zlib1g apt bind9-host bzip2 debian-archive-keyring gawk gnupg gpgv less
libbind9-40 libbz2-1.0 libcap2 libdns45 libisc45 libisccc40 libisccfg40
libkeyutils1 libkrb53 liblwres40 libreadline5 libssl0.9.8 libusb-0.1-4 libxml2
psmisc readline-common tree zip
#
--
FSF associate member #7257
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#557337: autofs5 insists on mounting localhost with --bind instead of -t nfs
Package: autofs5 Version: 5.0.3-3 Severity: minor I've wished to mount a localhost's filesystem over NFSv3, like: ## FIXME: use IPv6 when it'll become available for NFS on GNU/Linux ro.public -fstype=nfs,ro,nosuid,nodev,soft,intr,nolock,rsize=8192,wsize=8192 x.y.z.w:/var/public (where x.y.z.w is one of the host's addresses) in order to achieve a --bind-like mount, but read-only. Surprisingly enough, the FS was mounted with --bind instead! I was able to work-around the problem with: # iptables -t nat -A OUTPUT \ --destination=X.Y.Z.A \ -j DNAT --to-destination=X.Y.Z.W then specifying the NAT'ed address in the autofs5 configuration. PS. Hopefully I didn't make some silly mistake configuring the thing. -- FSF associate member #7257 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#557322: --exclude='ing essential packages
OS == Otavio Salvador ota...@ossystems.com.br writes:
OS retitle 557322 Improve manpage to explain that --exclude doesn't
OS affects dependency resolution thanks
[...]
IS However, it seems that it doesn't allow, say, initscripts co. to
IS be excluded:
# debootstrap --verbose --variant=minbase \
--exclude=initscripts,sysv{-rc,init{,-utils}},login,mount \
--include=bind9-host,bzip2,gawk,less,psmisc,tree,zip \
--keep-debootstrap-dir \
--print-debs \
lenny \
/tmp/$(date +%s)/ \
file:/com/waterlily.public/debian/
I: Retrieving Release
I: Retrieving Packages
I: Validating Packages
I: Resolving dependencies of required packages...
I: Resolving dependencies of base packages...
I: Found additional base dependencies: debian-archive-keyring gnupg gpgv
libbind9-40 libbz2-1.0 libcap2 libdns45 libisc45 libisccc40 libisccfg40
libkeyutils1 libkrb53 liblwres40 libreadline5 libssl0.9.8 libusb-0.1-4
libxml2 readline-common
[...]
OS To you exclude a package you also need to exclude all one that
OS depends on it otherwise it will be added back into the installation
OS list by the dependency resolution code.
Is it really the whole problem? What other package(s) I should
--exclude= as well considering the case above?
OS I'm changing the title of the bug to improve this part of the
OS manpage since it ought to be cited there to avoid confusion.
Please note that:
* the ``Found additional base dependencies:'' line doesn't
report any of the `--exclude='d packages among those brought
by the dependencies;
* chroot(8)ing into the system and `apt-get remove'ing the very
same set of packages:
# apt-get remove initscripts sysv{-rc,init{,-utils}} login mount
doesn't remove any package out of this set; (though it
complains on essentiality, of course.)
TIA.
--
FSF associate member #7257
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#441361: no support for NFS (v3) mount over IPv6?
SHG == Steinar H Gunderson sgunder...@bigfoot.com writes: [...] IS But mount.nfs doesn't find records for hosts, and it also IS can't parse numeric IPv6 addresses on account of all the colons. SHG For the bug reference, preliminary IPv6-supporting packages SHG (client side only) I've got it. Sigh. I had some big plans for it. (Perhaps I should change the Debian GNU/Linux server to something like OpenSolaris? Just kidding, of course.) And also: http://article.gmane.org/gmane.linux.nfs/29288 http://article.gmane.org/gmane.linux.nfs/29294 --cut: http://article.gmane.org/gmane.linux.nfs/29294 -- Server side in the kernel is nearly done. There are a handful of small patches outstanding. Until I have mountd working, there's no way to test the server side pieces thoroughly. So for now, completion of the server side is some time in the future. + userspace support - nfsd support has already been added but disabled temporarily till we get statd and mountd IPv6 aware. - making statd IPv6 aware is currently under development/review. Basic support is code complete and has seen some testing. We're waiting for upstream NFS maintainers to review the latest patch series. - mount.nfs changes - done? The netid changes mentioned above will require some mount.nfs support, which is in the works. 2.6.33, maybe? - rpc.mountd, exportfs changes - TBD. These are the next step. This is going to be a fairly heavy-weight change -- mountd and exportfs internals are unsuited for internationalized domain names, IPv6, and mixed IPv4/IPv6 environments, and will need to be replaced. [...] rpcbind and libtirpc are also prerequisites, but there are few distributions I know of that have replaced portmapper with rpcbind. How far we are from getting full IPv6 support? The short answer is mountd/exportfs will take about six months. The client side is close enough that I think we can promise basic IPv6 support for upcoming enterprise releases. We're also thinking the kernel work on the server is close enough that few or no kABI changes will be needed once mountd is working, but that's just a guess. --cut: http://article.gmane.org/gmane.linux.nfs/29294 -- -- FSF associate member #7257 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#441361: current state of IPv6 support in Debian
The following message is a courtesy copy of an article that has been posted to gmane.linux.debian.devel.ipv6 as well. IS == Ivan Shmakov i...@main.uusia.org writes: [...] IS Given that I now have rpcbind running, I wonder, what should be IS done for nfs-utils to support NFS over IPv6 as well? IS Is it just a matter of adding --enable-ipv6 and --enable-tirpc to IS the configure command line? [...] So far, I've worked around Bug#544567, built the nfs-utils package from Debian Squeeze with the change suggested above for Debian Lenny, and, finally, did: users # apt-get install -V nfs-kernel-server=1:1.2.0-4.is+0.4~bpo50~is+0.1 ... Setting up nfs-kernel-server (1:1.2.0-4.is+0.4~bpo50~is+0.1) ... Starting NFS common utilities: statd. Exporting directories for NFS kernel daemon Starting NFS kernel daemon: nfsd mountd. users # exportfs users # exportfs -o ro,all_squash \*:/var/public users # mount -t nfs -o ro,nosuid,nodev users.test1.ipv6.uusia.org:/var/public /mnt/ ... And saw my linux.uml instance (as of user-mode-linux 2.6.26-1um-2+15) go nuts! But nevertheless, it doesn't complain on users.test1.ipv6.uusia.org having no IPv4 address anymore. (Looks like I'll have to do some testing under KVM instead.) * See also http://bugs.debian.org/441361 http://bugs.debian.org/544567 http://permalink.gmane.org/gmane.linux.debian.backports.general/5762 -- FSF associate member #7257 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#556439: -lmfhdf alone should imply -ldf, too
Package: libhdf4-dev Version: 4.2r4-6 Severity: minor Currently, linking against libmfhdf.so alone fails like: $ gcc -o /dev/null ncattput.c -lmfhdf /usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../../lib/libmfhdf.so: undefined reference to `DFKisnativeNT' /usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../../lib/libmfhdf.so: undefined reference to `DFdiput' /usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../../lib/libmfhdf.so: undefined reference to `Hinquire' ... /usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../../lib/libmfhdf.so: undefined reference to `Vattach' /usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../../lib/libmfhdf.so: undefined reference to `VSgetclass' collect2: ld returned 1 exit status $ This is because libmfhdf.so lacks a dependency on libdf.so (e. g., -ldf was missing at this library's linking time): $ ldd /usr/lib/libmfhdf.so linux-vdso.so.1 = (0x7fffe83fe000) libjpeg.so.62 = /usr/lib/libjpeg.so.62 (0x7f38dfd86000) libz.so.1 = /usr/lib/libz.so.1 (0x7f38dfb6f000) libgfortran.so.3 = /usr/lib/libgfortran.so.3 (0x7f38df893000) libm.so.6 = /lib/libm.so.6 (0x7f38df61) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x7f38df3f9000) libc.so.6 = /lib/libc.so.6 (0x7f38df0a5000) /lib64/ld-linux-x86-64.so.2 (0x7f38e01ed000) $ May I suggest adding such a dependency? -- FSF associate member #7257 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#555411: inconsistent underscores in Fortran interface functions names
So far, I was able to use the following interdiff to seemingly
make the package suit my needs. Please consider applying its
relevant portions to the Debian package.
--cut--
diff -u hdf-eos4-2.16v1.00.dfsg.1/debian/control
hdf-eos4-2.16v1.00.dfsg.1/debian/control
--- hdf-eos4-2.16v1.00.dfsg.1/debian/control
+++ hdf-eos4-2.16v1.00.dfsg.1/debian/control
@@ -4,13 +4,12 @@
Maintainer: Alastair McKinstry mckins...@debian.org
Standards-Version: 3.8.3
Homepage: http://www.hdfeos.org
-Build-Depends: cdbs, debhelper ( 7), dh-buildinfo, gfortran, libhdf4g-dev,
libjpeg62-dev, zlib1g-dev, libgctp-dev, chrpath, autoconf, automake
+Build-Depends: cdbs, debhelper ( 7), dh-buildinfo, gfortran, libhdf4g-dev,
libjpeg62-dev, zlib1g-dev, libgctp-dev, chrpath, autoconf, automake, libtool
Build-Conflicts: autoconf2.13
Package: libhdfeos0
Architecture: any
Depends: ${misc:Depends}, ${shlibs:Depends}
-Conflicts: libhe5-hdfeos0
Description: Earth Observation System extensions to HDF4
HDF-EOS4 is a software library designed built on HDF4 to support EOS-specific
data structures, namely Grid, Point, and Swath. The new data structures
@@ -24,7 +23,6 @@
Architecture: any
Section: libdevel
Depends: libhdfeos0 (= ${binary:Version}), ${misc:Depends}
-Conflicts: libhe5-hdfeos0
Recommends: pkg-config
Description: Development files for the HDF-EOS4 library
HDF-EOS4 is a software library designed built on HDF4 to support EOS-specific
diff -u hdf-eos4-2.16v1.00.dfsg.1/debian/changelog
hdf-eos4-2.16v1.00.dfsg.1/debian/changelog
--- hdf-eos4-2.16v1.00.dfsg.1/debian/changelog
+++ hdf-eos4-2.16v1.00.dfsg.1/debian/changelog
@@ -1,3 +1,24 @@
+hdf-eos4 (2.16v1.00.dfsg.1-2.is+0.3) 1gray-misc; urgency=low
+
+ * Hack debian/rules so that make check will find all the necessary
+Fortran sources.
+
+ -- Ivan Shmakov i...@main.uusia.org Tue, 10 Nov 2009 21:14:23 +0600
+
+hdf-eos4 (2.16v1.00.dfsg.1-2.is+0.2) unstable; urgency=low
+
+ * Clear CFLAGS.
+
+ -- Ivan Shmakov i...@main.uusia.org Tue, 10 Nov 2009 20:23:20 +0600
+
+hdf-eos4 (2.16v1.00.dfsg.1-2.is+0.1) 1gray-misc; urgency=low
+
+ * Added -Df2cFortran to CPPFLAGS. Closes: #555411.
+ * Removed Conflicts: libhe5-hdfeos0. Closes: #23.
+ * Added Build-Depends: libtool. Closes: #555152.
+
+ -- Ivan Shmakov i...@main.uusia.org Tue, 10 Nov 2009 13:12:52 +0600
+
hdf-eos4 (2.16v1.00.dfsg.1-2) unstable; urgency=low
* Add autoconf, asutomake dependencies for autoreconf. Closes: #546352.
diff -u hdf-eos4-2.16v1.00.dfsg.1/debian/rules
hdf-eos4-2.16v1.00.dfsg.1/debian/rules
--- hdf-eos4-2.16v1.00.dfsg.1/debian/rules
+++ hdf-eos4-2.16v1.00.dfsg.1/debian/rules
@@ -7,7 +7,9 @@
DEB_MAKE_CHECK_TARGET := check
DEB_MAKE_CLEAN_TARGET := clean distclean maintainer-clean
DEB_CONFIGURE_EXTRA_FLAGS := --enable-shared --with-pic
-DEB_CONFIGURE_SCRIPT_ENV += CFLAGS=-I/usr/include/hdf
+DEB_CONFIGURE_SCRIPT_ENV += \
+CFLAGS= \
+CPPFLAGS=-Df2cFortran -I/usr/include/hdf
clean::
[ ! -f Makefile ] || $(MAKE) distclean
@@ -15,6 +17,9 @@
makebuilddir/libhdfeos-dev::
# Needed for the pthreads tests
cp samples/simple.txt testdrivers/threads
+ ## FIXME: a sort of hack
+ ln -sf -- testswath.f testdrivers/swath/testswath77.f
+ ln -sf -- testpoint.f testdrivers/point/testpoint77.f
autoreconf
configure/libhdfeos0::
--cut--
BTW, I wasn't able to build i386 binaries: the # pbuilder build
process has failed with:
--cut--
rm -f Swath_2.hdf Swathc_Test.hdf Swathf_Test.hdf testswathf.txt
./testswath_f90
*** glibc detected ***
/tmp/buildd/hdf-eos4-2.16v1.00.dfsg.1/testdrivers/swath/.libs/lt-testswath_f90:
free(): invalid next size (fast): 0x087adbe0 ***
=== Backtrace: =
/lib/libc.so.6[0x55897af5]
/lib/libc.so.6(cfree+0x9c)[0x558993ac]
/tmp/buildd/hdf-eos4-2.16v1.00.dfsg.1/src/.libs/libhdfeos.so.0(swinqimaps_+0xff)[0x555b78fe]
/tmp/buildd/hdf-eos4-2.16v1.00.dfsg.1/testdrivers/swath/.libs/lt-testswath_f90[0x80558b8]
/tmp/buildd/hdf-eos4-2.16v1.00.dfsg.1/testdrivers/swath/.libs/lt-testswath_f90[0x805c2c9]
/lib/libc.so.6(__libc_start_main+0xe5)[0x558437a5]
/tmp/buildd/hdf-eos4-2.16v1.00.dfsg.1/testdrivers/swath/.libs/lt-testswath_f90[0x80491e1]
=== Memory map:
--cut--
Please note that the building of the Debian package doesn't
include building of the Fortran programs below testdrivers/, so
I'm not yet sure that it's I who's responsive for this failure.
I've put the resulting the source and amd64 binary packages at:
http://waterlily.ipv6.uusia.org/~ivan/mini-dinstall/1gray-misc/source/hdf-eos4_2.16v1.00.dfsg.1-2.is+0.3.diff.gz
http://waterlily.ipv6.uusia.org/~ivan/mini-dinstall/1gray-misc/source/hdf-eos4_2.16v1.00.dfsg.1-2.is+0.3.dsc
http://waterlily.ipv6.uusia.org/~ivan/mini-dinstall/1gray-misc/amd64/libhdfeos-dev_2.16v1.00.dfsg.1-2.is+0.3_amd64.deb
http://waterlily.ipv6.uusia.org/~ivan/mini-dinstall/1gray-misc/amd64
Bug#555411: inconsistent underscores in Fortran interface functions names
IS == Ivan Shmakov i...@main.uusia.org writes: [...] IS debian/rules reads: 10 DEB_CONFIGURE_SCRIPT_ENV += CFLAGS=-I/usr/include/hdf IS Surely it shouldn't be 10 DEB_CONFIGURE_SCRIPT_ENV += CPPFLAGS=-Df2cFortran -I/usr/include/hdf IS instead? Or, rather: 10 DEB_CONFIGURE_SCRIPT_ENV += \ 11 CFLAGS= \ 12 CPPFLAGS=-Df2cFortran -I/usr/include/hdf since the change as suggested above does allow -g -O2 to be passed through, while the original CFLAGS=-I/usr/include/hdf setting does not. (BTW, was the latter effect intended?) [...] -- FSF associate member #7257 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#555642: inconsistent underscores in Fortran interface functions' names
Source: hdf-eos5 Version: 2.16v1.00.dfsg.1-2 There's an issue similar to Bug#555411: $ nm libhe5-hdfeos-dev_5.1.12.dfsg.1-2_amd64/usr/lib/libhe5_hdfeos.a \ | grep -E _\$ U _GLOBAL_OFFSET_TABLE_ U _GLOBAL_OFFSET_TABLE_ U _GLOBAL_OFFSET_TABLE_ U _GLOBAL_OFFSET_TABLE_ U _GLOBAL_OFFSET_TABLE_ U _GLOBAL_OFFSET_TABLE_ $ Once again, the Fortran interface functions' names lack a trailing underscore. However, the obvious change --cut-- diff -u hdf-eos5-5.1.12.dfsg.1/debian/rules hdf-eos5-5.1.12.dfsg.1/debian/rules --- hdf-eos5-5.1.12.dfsg.1/debian/rules +++ hdf-eos5-5.1.12.dfsg.1/debian/rules @@ -6,8 +6,11 @@ DEB_MAKE_CHECK_TARGET := check DEB_MAKE_CLEAN_TARGET := clean distclean maintainer-clean -DEB_CONFIGURE_EXTRA_FLAGS := --enable-shared --with-pic -DEB_CONFIGURE_SCRIPT_ENV += CFLAGS=-D_HDFEOS5_THREADSAFE +DEB_CONFIGURE_EXTRA_FLAGS := --enable-shared --with-pic \ +he2_cv_fortran90_compiler=no +DEB_CONFIGURE_SCRIPT_ENV += \ +CFLAGS= \ +CPPFLAGS=-D_HDFEOS5_THREADSAFE -Df2cFortran DEB_AUTO_UPDATE_LIBTOOL := pre clean:: --cut-- has resulted in an unfortunate FTBFS: --cut-- libtool: link: cc -o .libs/he5_za_writedata he5_za_writedata.o ../src/.libs/lib he5_hdfeos.so -lgctp /usr/lib/libhdf5.so -lz -lm gfortran -g -O2 -c -o he5_gd_definefieldsF_64.o he5_gd_definefieldsF_64.f /bin/bash ../libtool --tag=F77 --mode=link gfortran -g -O2 -o he5_gd_definefieldsF_64 he5_gd_definefieldsF_64.o ../src/libhe5_hdfeos.la -lgctp -lhdf5 -lz -lm libtool: link: unsupported hardcode properties libtool: link: See the libtool documentation for more information. libtool: link: Fatal configuration error. make[3]: *** [he5_gd_definefieldsF_64] Error 1 make[3]: Leaving directory `/tmp/buildd/hdf-eos5-5.1.12.dfsg.1/samples' --cut-- Since I don't know how to solve fix this problem properly, I've temporarily hacked the Fortran tests out as shown in the full interdiff below. Looks like these tests weren't built for the Debian package, anyway. For anyone interested, I've put the resulting the source and amd64 binary packages at: http://waterlily.ipv6.uusia.org/~ivan/mini-dinstall/1gray-misc/source/hdf-eos5_5.1.12.dfsg.1-2.is+0.2.diff.gz http://waterlily.ipv6.uusia.org/~ivan/mini-dinstall/1gray-misc/source/hdf-eos5_5.1.12.dfsg.1-2.is+0.2.dsc http://waterlily.ipv6.uusia.org/~ivan/mini-dinstall/1gray-misc/amd64/libhe5-hdfeos0_5.1.12.dfsg.1-2.is+0.2_amd64.deb http://waterlily.ipv6.uusia.org/~ivan/mini-dinstall/1gray-misc/amd64/libhe5-hdfeos-dev_5.1.12.dfsg.1-2.is+0.2_amd64.deb http://waterlily.ipv6.uusia.org/~ivan/mini-dinstall/1gray-misc/i386/libhe5-hdfeos0_5.1.12.dfsg.1-2.is+0.2_i386.deb http://waterlily.ipv6.uusia.org/~ivan/mini-dinstall/1gray-misc/i386/libhe5-hdfeos-dev_5.1.12.dfsg.1-2.is+0.2_i386.deb --cut: /etc/apt/sources.list -- deb http://waterlily.ip.uusia.org/~ivan/mini-dinstall/ 1gray-misc/$(ARCH)/ deb http://waterlily.ip.uusia.org/~ivan/mini-dinstall/ 1gray-misc/all/ deb-src http://waterlily.ip.uusia.org/~ivan/mini-dinstall/ 1gray-misc/source/ --cut: /etc/apt/sources.list -- (I hope to perform some test builds using this and the packages built from hdf-eos4 later this week.) * The interdiff --cut-- diff -u hdf-eos5-5.1.12.dfsg.1/debian/changelog hdf-eos5-5.1.12.dfsg.1/debian/changelog --- hdf-eos5-5.1.12.dfsg.1/debian/changelog +++ hdf-eos5-5.1.12.dfsg.1/debian/changelog @@ -1,3 +1,17 @@ +hdf-eos5 (5.1.12.dfsg.1-2.is+0.2) 1gray-misc; urgency=low + + * Clear CFLAGS. + * Prevent Fortran code below samples/ and testdrivers/ from being built +and run. + + -- Ivan Shmakov i...@main.uusia.org Tue, 10 Nov 2009 23:23:15 +0600 + +hdf-eos5 (5.1.12.dfsg.1-2.is+0.1) 1gray-misc; urgency=low + + * Added -Df2cFortran to CPPFLAGS. + + -- Ivan Shmakov i...@main.uusia.org Tue, 10 Nov 2009 12:43:20 +0600 + hdf-eos5 (5.1.12.dfsg.1-2) unstable; urgency=low * Add autoconf, automake to Build-Depends. Closes: #545833. diff -u hdf-eos5-5.1.12.dfsg.1/debian/rules hdf-eos5-5.1.12.dfsg.1/debian/rules --- hdf-eos5-5.1.12.dfsg.1/debian/rules +++ hdf-eos5-5.1.12.dfsg.1/debian/rules @@ -6,8 +6,11 @@ DEB_MAKE_CHECK_TARGET := check DEB_MAKE_CLEAN_TARGET := clean distclean maintainer-clean -DEB_CONFIGURE_EXTRA_FLAGS := --enable-shared --with-pic -DEB_CONFIGURE_SCRIPT_ENV += CFLAGS=-D_HDFEOS5_THREADSAFE +DEB_CONFIGURE_EXTRA_FLAGS := --enable-shared --with-pic \ +he2_cv_fortran90_compiler=no +DEB_CONFIGURE_SCRIPT_ENV += \ +CFLAGS= \ +CPPFLAGS=-D_HDFEOS5_THREADSAFE -Df2cFortran DEB_AUTO_UPDATE_LIBTOOL := pre clean:: only in patch2: unchanged: --- hdf-eos5-5.1.12.dfsg.1.orig/configure.ac +++ hdf-eos5-5.1.12.dfsg.1/configure.ac @@ -582,6 +582,14 @@ header files should enable this option.])], [INSTALL_INCLUDE=$enableval
Bug#555411: inconsistent underscores in Fortran interface functions names
IS == Ivan Shmakov i...@main.uusia.org writes:
[...]
IS BTW, I wasn't able to build i386 binaries: the # pbuilder build
IS process has failed with:
--cut--
rm -f Swath_2.hdf Swathc_Test.hdf Swathf_Test.hdf testswathf.txt
./testswath_f90
*** glibc detected ***
/tmp/buildd/hdf-eos4-2.16v1.00.dfsg.1/testdrivers/swath/.libs/lt-testswath_f90:
free(): invalid next size (fast): 0x087adbe0 ***
I was able to overcome this problem by disabling the Fortran
code below testdrivers/ entirely, like:
--cut--
diff -u hdf-eos4-2.16v1.00.dfsg.1/debian/rules
hdf-eos4-2.16v1.00.dfsg.1/debian/rules
--- hdf-eos4-2.16v1.00.dfsg.1/debian/rules
+++ hdf-eos4-2.16v1.00.dfsg.1/debian/rules
@@ -6,7 +6,8 @@
DEB_MAKE_CHECK_TARGET := check
DEB_MAKE_CLEAN_TARGET := clean distclean maintainer-clean
-DEB_CONFIGURE_EXTRA_FLAGS := --enable-shared --with-pic
+DEB_CONFIGURE_EXTRA_FLAGS := --enable-shared --with-pic \
+he2_cv_fortran90_compiler=no
DEB_CONFIGURE_SCRIPT_ENV += \
CFLAGS= \
CPPFLAGS=-Df2cFortran -I/usr/include/hdf
diff -u hdf-eos4-2.16v1.00.dfsg.1/debian/changelog
hdf-eos4-2.16v1.00.dfsg.1/debian/changelog
--- hdf-eos4-2.16v1.00.dfsg.1/debian/changelog
+++ hdf-eos4-2.16v1.00.dfsg.1/debian/changelog
@@ -1,3 +1,10 @@
+hdf-eos4 (2.16v1.00.dfsg.1-2.is+0.4) 1gray-misc; urgency=low
+
+ * Pass he2_cv_fortran90_compiler=no to configure, effectively disabling
+Fortran90 tests; hack configure.ac to allow it.
+
+ -- Ivan Shmakov i...@main.uusia.org Tue, 10 Nov 2009 22:44:33 +0600
+
hdf-eos4 (2.16v1.00.dfsg.1-2.is+0.3) 1gray-misc; urgency=low
* Hack debian/rules so that make check will find all the necessary
only in patch2:
unchanged:
--- hdf-eos4-2.16v1.00.dfsg.1.orig/configure.ac
+++ hdf-eos4-2.16v1.00.dfsg.1/configure.ac
@@ -204,11 +204,13 @@
if test -n $FC; then
AC_MSG_CHECKING([for fortran compiler $FC])
AC_LANG_PUSH([Fortran])
+AC_CACHE_VAL([he2_cv_fortran90_compiler], [
AC_TRY_LINK([], [
INTEGER :: I
REAL :: R
I=TRANSFER(R,I)
], [he2_cv_fortran90_compiler=yes], [he2_cv_fortran90_compiler=no])
+])
AC_LANG_POP([Fortran])
if test ${he2_cv_fortran90_compiler} = yes; then
AC_MSG_RESULT([Fortran 90 code was successfully compiled; assume f90 or
later])
--cut--
[...]
I've put the resulting the source and binary (amd64, i386)
packages at:
http://waterlily.ipv6.uusia.org/~ivan/mini-dinstall/1gray-misc/source/hdf-eos4_2.16v1.00.dfsg.1-2.is+0.4.diff.gz
http://waterlily.ipv6.uusia.org/~ivan/mini-dinstall/1gray-misc/source/hdf-eos4_2.16v1.00.dfsg.1-2.is+0.4.dsc
http://waterlily.ipv6.uusia.org/~ivan/mini-dinstall/1gray-misc/amd64/libhdfeos-dev_2.16v1.00.dfsg.1-2.is+0.4_amd64.deb
http://waterlily.ipv6.uusia.org/~ivan/mini-dinstall/1gray-misc/amd64/libhdfeos0_2.16v1.00.dfsg.1-2.is+0.4_amd64.deb
http://waterlily.ipv6.uusia.org/~ivan/mini-dinstall/1gray-misc/i386/libhdfeos-dev_2.16v1.00.dfsg.1-2.is+0.4_i386.deb
http://waterlily.ipv6.uusia.org/~ivan/mini-dinstall/1gray-misc/i386/libhdfeos0_2.16v1.00.dfsg.1-2.is+0.4_i386.deb
--cut: /etc/apt/sources.list --
deb http://waterlily.ip.uusia.org/~ivan/mini-dinstall/ 1gray-misc/$(ARCH)/
deb http://waterlily.ip.uusia.org/~ivan/mini-dinstall/ 1gray-misc/all/
deb-src http://waterlily.ip.uusia.org/~ivan/mini-dinstall/ 1gray-misc/source/
--cut: /etc/apt/sources.list --
--
FSF associate member #7257
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#555411: inconsistent underscores in Fortran interface functions names
Source: hdf-eos4 Version: 2.16v1.00.dfsg.1-2 debian/rules reads: 10 DEB_CONFIGURE_SCRIPT_ENV += CFLAGS=-I/usr/include/hdf Surely it shouldn't be 10 DEB_CONFIGURE_SCRIPT_ENV += CPPFLAGS=-Df2cFortran -I/usr/include/hdf instead? * Rationale I don't know where this custom originated from, neither whether it's still in use. But nevertheless still, the functions that are intended to be called from Fortran bear a leading underscore or two, like: $ nm libgctp-dev_1.0-1_i386/usr/lib/libgctp.a | grep -E _\$ T gctp_ $ As of hdf-eos4 2.16v1.00.dfsg.1-2, no function is like that, not even the functions that are, in fact, intended to be called from Fortran: $ nm libhdfeos-dev_2.16v1.00.dfsg.1-2_i386/usr/lib/libhdfeos.a | grep -E _\$ $ I don't mind much about which way is right, but since one can't use both -funderscoring and -fno-underscoring at the same time, I plead for a bit of consistency here. * See also http://gcc.gnu.org/onlinedocs/gcc-4.4.2/gfortran/Code-Gen-Options.html#index-g_t_0040code_007bfno_002dunderscoring_007d-207 -- FSF associate member #7257 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#555523: particular software may require both HDF-EOS and HDF-EOS5 to build
Source: hdf-eos4-2.16v1.00.dfsg.1 Version: 2.16v1.00.dfsg.1-2 Currently, both libhdfeos0 and libhdfeos-dev have Conflicts: libhe5-hdfeos0. This is unfortunate, since there're software packages (say, SDP Toolkit) which require both HDF-EOS and HDF-EOS5 to build. -- FSF associate member #7257 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544567: current state of IPv6 support in Debian
The following message is a courtesy copy of an article that has been posted to gmane.linux.debian.devel.ipv6 as well. IS == Ivan Shmakov oneing...@gmail.com writes: [...] IS portmap -- lacks IPv6 support, necessary for NFS over IPv6 to work IS (Bug#515128); Well, a trivial change (below) has seemingly made rpcbind installable and Bug#544567 be worked-around. But I still have no clue what should be the proper fix? [...] diff -u rpcbind-0.2.0/debian/rules rpcbind-0.2.0/debian/rules --- rpcbind-0.2.0/debian/rules +++ rpcbind-0.2.0/debian/rules @@ -51,6 +51,8 @@ # Add here commands to install the package into debian/rpcbind. $(MAKE) DESTDIR=$(CURDIR)/debian/rpcbind install + mv -- debian/rpcbind/usr/bin/rpcinfo \ + debian/rpcbind/usr/bin/rpcinfo.rpcbind # Build architecture-independent files here. @@ -79,6 +81,8 @@ dh_link dh_strip dh_compress + mv -- debian/rpcbind/usr/share/man/man8/rpcinfo.8.gz \ + debian/rpcbind/usr/share/man/man8/rpcinfo.rpcbind.8.gz dh_fixperms # dh_perl # dh_makeshlibs diff -u rpcbind-0.2.0/debian/changelog rpcbind-0.2.0/debian/changelog --- rpcbind-0.2.0/debian/changelog +++ rpcbind-0.2.0/debian/changelog @@ -1,3 +1,21 @@ +rpcbind (0.2.0-1.is+0.3) unstable; urgency=low + + * Fixed one more time. + + -- Ivan Shmakov i...@main.uusia.org Sat, 19 Sep 2009 13:45:05 +0700 + +rpcbind (0.2.0-1.is+0.2) unstable; urgency=low + + * Renamed rpcinfo.8, too. + + -- Ivan Shmakov i...@main.uusia.org Sat, 19 Sep 2009 13:42:30 +0700 + +rpcbind (0.2.0-1.is+0.1) unstable; urgency=low + + * Renamed rpcinfo to rpcinfo.rpcbind (closes: #544567) + + -- Ivan Shmakov i...@main.uusia.org Sat, 19 Sep 2009 11:13:49 +0700 + rpcbind (0.2.0-1) unstable; urgency=low * Initial release -- FSF associate member #7257 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#441361: current state of IPv6 support in Debian
The following message is a courtesy copy of an article
that has been posted to gmane.linux.debian.devel.ipv6 as well.
IS == Ivan Shmakov i...@main.uusia.org writes:
IS Well, a trivial change (below) has seemingly made rpcbind
IS installable and Bug#544567 be worked-around. But I still have no
IS clue what should be the proper fix?
Given that I now have rpcbind running, I wonder, what should be
done for nfs-utils to support NFS over IPv6 as well?
Is it just a matter of adding --enable-ipv6 and --enable-tirpc
to the configure command line? (And if it's so, could someone
with a Debian Squeeze at hand try building nfs-utils (1.2.0-4)
changed as shown by the interdiff below?)
$ interdiff (zcat .../pool/main/n/nfs-utils/nfs-utils_1.2.0-4.diff.gz) \
(zcat nfs-utils_1.2.0-4.is+0.2.diff.gz)
diff -u nfs-utils-1.2.0/debian/rules nfs-utils-1.2.0/debian/rules
--- nfs-utils-1.2.0/debian/rules
+++ nfs-utils-1.2.0/debian/rules
@@ -23,6 +23,8 @@
dh_testdir
CFLAGS=$(CFLAGS) ./configure \
--mandir='$${prefix}/share/man' \
+ --enable-ipv6 \
+ --enable-tirpc \
--with-tcp-wrappers
$(MAKE) $(MAKEFLAGS)
touch build-stamp
diff -u nfs-utils-1.2.0/debian/control nfs-utils-1.2.0/debian/control
--- nfs-utils-1.2.0/debian/control
+++ nfs-utils-1.2.0/debian/control
@@ -2,7 +2,7 @@
Priority: standard
Section: net
Maintainer: Anibal Monsalve Salazar ani...@debian.org
-Build-Depends: debhelper (= 5), libwrap0-dev, libevent-dev, libnfsidmap-dev,
libkrb5-dev, libgssglue-dev, librpcsecgss-dev (= 0.17), libblkid-dev,
libkeyutils-dev, pkg-config, quilt (= 0.40), libldap2-dev
+Build-Depends: debhelper (= 5), libwrap0-dev, libevent-dev, libnfsidmap-dev,
libkrb5-dev, libgssglue-dev, librpcsecgss-dev (= 0.17), libblkid-dev,
libkeyutils-dev, pkg-config, quilt (= 0.40), libldap2-dev, libtirpc-dev
Standards-Version: 3.8.1
Homepage: http://nfs.sourceforge.net/
diff -u nfs-utils-1.2.0/debian/changelog nfs-utils-1.2.0/debian/changelog
--- nfs-utils-1.2.0/debian/changelog
+++ nfs-utils-1.2.0/debian/changelog
@@ -1,3 +1,16 @@
+nfs-utils (1:1.2.0-4.is+0.2) unstable; urgency=low
+
+ * Add --enable-tirpc to configure.
+ * Depend on libtirpc-dev.
+
+ -- Ivan Shmakov i...@main.uusia.org Thu, 05 Nov 2009 00:59:08 +0600
+
+nfs-utils (1:1.2.0-4.is+0.1) 1gray-misc; urgency=low
+
+ * Add --enable-ipv6 to configure.
+
+ -- Ivan Shmakov i...@main.uusia.org Thu, 05 Nov 2009 00:45:54 +0600
+
nfs-utils (1:1.2.0-4) unstable; urgency=low
* Removing myself from uploaders.
[...]
--
FSF associate member #7257
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551723: hdf4-tools should contain Conflicts: libhdf4g-run
Package: hdf4-tools Version: 4.2r4-6 Please consider adding a Conflicts: field to the hdf4-tools package description. # apt-get install -V -t squeeze hdf4-tools Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: libgs8 (8.70~dfsg-2) libcupsimage2 (1.4.1-4) Use 'apt-get autoremove' to remove them. The following NEW packages will be installed: hdf4-tools (4.2r4-6) 0 upgraded, 1 newly installed, 0 to remove and 1035 not upgraded. 5 not fully installed or removed. Need to get 0B/249kB of archives. After this operation, 697kB of additional disk space will be used. (Reading database ... 166002 files and directories currently installed.) Unpacking hdf4-tools (from .../hdf4-tools_4.2r4-6_i386.deb) ... dpkg: error processing /[...]/libhdf4/hdf4-tools_4.2r4-6_i386.deb (--unpack): trying to overwrite `/usr/bin/hdp', which is also in package libhdf4g-run dpkg-deb: subprocess paste killed by signal (Broken pipe) Errors were encountered while processing: /[...]/debian/pool/main/libh/libhdf4/hdf4-tools_4.2r4-6_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) # -- FSF associate member #7257 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551726: qemu-img(1) doesn't actually support images created by uml_mkcow(1)
Package: qemu Version: 0.9.1-10lenny1 Severity: minor Despite claiming to be compatible, --cut: qemu-img(1) -- cow User Mode Linux Copy On Write image format. Used to be the only growable image format in QEMU. It is supported only for compatibility with previous versions. It does not work on win32. --cut: qemu-img(1) -- qemu-img(1) fails to actually support the .cow files produced by uml_mkcow(1), at least on amd64: $ qemu-img info 1255869863.cow image: 1255869863.cow file format: raw virtual size: 4.0G (4296024064 bytes) disk size: 3.6G $ qemu-img info -f cow 1255869863.cow qemu-img: Could not open '1255869863.cow' $ $ LC_ALL=C dpkg -l uml-utilities qemu Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- ii qemu 0.9.1-10lenny1 fast processor emulator ii uml-utilities 20070815-1.1 User-mode Linux (utility programs) $ -- FSF associate member #7257 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551723: [DebianGIS-dev] Bug#551723: hdf4-tools should contain Conflicts: libhdf4g-run
Francesco P Lovergine fran...@debian.org writes: Package: hdf4-tools Version: 4.2r4-6 Please consider adding a Conflicts: field to the hdf4-tools package description. It was already conflicting in 4.1r4-22 and removed after lenny release. Are you trying to update directly from pre-lenny to squeeze? Ouch. Indeed, I did. Sorry for the noise. 2009-10-20 14:06:32 remove libhdf4g-run 4.1r4-18.1 4.1r4-18.1 -- FSF associate member #7257 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544472: server certificate verification fails when connecting as an SMTP client?
AM == Andreas Metzler ametz...@downhill.at.eu.org writes: [...] AM thank you for the pointer. I have made a preliminary patch and have AM forwarded this upstream to AM http://bugs.exim.org/show_bug.cgi?id=888. Thanks! At the first glance, the patch looks quite appropriate. + *Note*: +These options must be set in the (smtp) transport ... May ``The aforementioned options...'' be better here? (For those who are going to scan over the text, at the least.) -- FSF associate member #7257 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545818: where's `ncdump-hdf', anyway?
Package: hdf4-tools
Version: 4.2r4-5
The libhdf4g-run package, which hdf4-tools is, IIUC, intended to
replace, contained the `ncdump-hdf' and `ncgen-hdf' programs,
which allowed easy transformation of the data between HDF4 and a
certain ASCII representation. However, these programs were, for
a reason unknown to me, excluded from hdf4-tools, and it seems
that no comparable replacement was provided.
For example, as of this hdf4-tools version, there's no easy way
to list the ``contents'' of an HDF4 file (field names,
dimensions, attributes) -- the information that has proven to be
vital for everyday use. Formely, it could be done with, say:
$ ncdump-hdf -h FILE.hdf | less
One of the 4.1st versions of the package that I have the sources
to had the following in the Debian .diff.gz:
$ zcat pool/main/libh/libhdf4/libhdf4_4.1r4-22.diff.gz
...
--- libhdf4-4.1r4.orig/debian/rules
+++ libhdf4-4.1r4/debian/rules
@@ -0,0 +1,211 @@
...
+binary-run:
...
+ # Rename ncgen and ncdump
+ mv debian/tmp-run/usr/bin/ncgen{,-hdf}
+ mv debian/tmp-run/usr/bin/ncdump{,-hdf}
...
$
The 4.2r4-5 has instead:
$ zcat pool/main/libh/libhdf4/libhdf4_4.2r4-5.diff.gz
--- libhdf4-4.2r4.orig/debian/rules
+++ libhdf4-4.2r4/debian/rules
@@ -0,0 +1,199 @@
...
+stamps/install-stamp: build-arch
...
+ # remove programs and manpages provided by netcdf-bin
+ rm -f $(DESTDIR)/usr/bin/ncdump $(DESTDIR)/usr/bin/ncgen
+ rm -f $(DESTDIR)/usr/share/man/man1/ncdump*
$(DESTDIR)/usr/share/man/man1/ncgen*
+
...
$
The comment provided is, to the best of my knowledge, wrong: the
versions of these programs provided by netcdf-bin are for NetCDF
files only, and have no relation (except of the one of the
``ancestry'' character) to HDF4.
Please consider bringing ncdump-hdf and ncgen-hdf back to the
Debian package.
TIA.
--
FSF associate member #7257
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#432351: Andrew McMillan's Squid packages
JFTR. For quite some time there're unofficial Squid to-be-3.1 packages by Andrew McMillan: http://andrew.mcmillan.net.nz/blog/squid_ipv6_debian_packages http://debian.mcmillan.net.nz/packages/squid3/ -- FSF associate member #7257 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545270: SDreaddata () fails on an amd64 system
Package: libhdf4g
Version: 4.1r4-22
Severity: grave
[Hopefully not a false positive.]
Apparently, SDreaddata () is broken on amd64. Consider, e. g.:
$ ncdump-hdf -h \
e4ftl01u.ecs.nasa.gov/MODIS_Composites/MOTA/MCD43B3.005/2006.08.29/MCD43B3.A2006241.h23v03.005.2008108002817.hdf
| head
netcdf MCD43B3.A2006241.h23v03.005.2008108002817 {
dimensions:
YDim_MOD_Grid_BRDF = 1200 ;
XDim_MOD_Grid_BRDF = 1200 ;
variables:
short Albedo_BSA_Band1(YDim_MOD_Grid_BRDF, XDim_MOD_Grid_BRDF) ;
Albedo_BSA_Band1:long_name = Albedo_BSA_Band1 ;
Albedo_BSA_Band1:units = albedo, no units ;
Albedo_BSA_Band1:valid_range = 0s, 32766s ;
$ hdp dumpsds -d \
-n Albedo_BSA_Band1 \
e4ftl01u.ecs.nasa.gov/MODIS_Composites/MOTA/MCD43B3.005/2006.08.29/MCD43B3.A2006241.h23v03.005.2008108002817.hdf
HDP ERROR in sdsdumpfull: SDreaddata failed for sds_id(262144).
HDP ERROR in printSD_ASCII: sdsdumpfull failed for 0'th SDS.
HDP ERROR in dsd: printSD_ASCII failed for file
e4ftl01u.ecs.nasa.gov/MODIS_Composites/MOTA/MCD43B3.005/2006.08.29/MCD43B3.A2006241.h23v03.005.2008108002817.hdf
$
It looks like that the ncvarget () interface still works:
$ hdfdump -T \
e4ftl01u.ecs.nasa.gov/MODIS_Composites/MOTA/MCD43B3.005/2006.08.29/MCD43B3.A2006241.h23v03.005.2008108002817.hdf
\
Albedo_BSA_Band1 | head
0.062
0.06
0.057
0.059
0.056
0.052
0.051
0.05
0.05
0.054
$
The file used in the example could be downloaded (24.9 MiB)
using anonymous FTP, like:
$ wget
ftp://e4ftl01u.ecs.nasa.gov/MODIS_Composites/MOTA/MCD43B3.005/2006.08.29/MCD43B3.A2006241.h23v03.005.2008108002817.hdf
--
FSF associate member #7257
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545270: SDreaddata () fails on an amd64 system
Upgrading to the version currently in Debian Lenny (4.2r4-5) seems to resolve the problem. Thanks. -- FSF associate member #7257 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#334681: unixodbc-dev shouldn't depend on libodbcinstq1c2
FWIW, I second the opinion that the part of unixodbc-dev depending on libodbcinstq1c2 should be split off the package. Unfortunately, as it appears, there're people who don't own nor have access to a sheer number of computers that they could do builds on, in order to relieve their servers of such tasks. As a quick dirty hack, I've put the following dummy entry into my /var/lib/dpkg/status: Package: libodbcinstq1c2 Status: install ok installed Priority: optional Section: libs Version: 2.2.11-16 So far, everything works fine. -- FSF associate member #7257 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545118: update-exim4.conf should
Package: exim4-config Version: 4.69-9 The leftover DEBCONF strings check should consider the same set of files that the run_parts function does. In particular, update-exim4.conf should ignore any *~ files in conf.d/, like: --- update-exim4.conf 2008-10-01 01:27:02 +0700 +++ update-exim4.conf 2009-09-05 12:33:24 +0700 @@ -421,8 +421,10 @@ # check for left-over DEBCONF strings that may cause installation trouble # (fix PEBCAK for people who don't accept conffile changes and don't # read docs) -if grep -qr '^[^#]*DEBCONF[[:lower:]_]\+DEBCONF' $UPEX4C_confd $TEMPLATEFILE \ -! grep -qr '^[[:space:]]*DEBCONFstringOK_config_adapted[[:space:]]*=' $UPEX4C_confd $TEMPLATEFILE; then +if grep -qr '^[^#]*DEBCONF[[:lower:]_]\+DEBCONF' \ + --exclude=\*~ $UPEX4C_confd $TEMPLATEFILE \ +! grep -qr '^[[:space:]]*DEBCONFstringOK_config_adapted[[:space:]]*=' \ + --exclude=\*~ $UPEX4C_confd $TEMPLATEFILE; then errormessage DEBCONFsomethingDEBCONF found in exim configuration. This is most probably caused by you upgrading to exim4 4.67-3 or later without accepting the suggested conffile changes. Please read /usr/share/doc/exim4-config/NEWS.Debian.gz for 4.67-2 and 4.67-4 fi (Also note that given the Shell variable value substitution rules, the fragment above should read $UPEX4C_confd $TEMPLATEFILE, not $UPEX4C_confd $TEMPLATEFILE, in order to behave consistently should any of these two variables ever be set to a value containing a whitespace.) -- FSF associate member #7257 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544472: server certificate verification fails when connecting as an SMTP client?
Andreas Metzler ametz...@downhill.at.eu.org writes: Ivan Shmakov i...@main.uusia.org wrote: [...] It seems that the certificate verification fails when Exim connects to the peer, while should the peer in question connect to Exim, it succeeds. [...] Note the CV=yes vs. CV=no discrepancy. Hello, Afaict you have provided exim with a list of trusted certificates to check incoming connections (main configuration option tls_verify_certificates) against but you have not toggled the corresponding option for outgoing connections (the tls_verify_certificates private option of the smtp transport). I've known that I've made some silly mistake! I've fixed that and it works as expected now, thanks! However, the documentation is somewhat unclear on that matter: --cut: (exim4) Configuring an Exim client to use TLS -- The `tls_certificate' and `tls_privatekey' options of the `smtp' transport provide the client with a certificate, which is passed to the server if it requests it. If the server is Exim, it will request a certificate only if `tls_verify_hosts' or `tls_try_verify_hosts' matches the client. *Note*: These options must be set in the `smtp' transport for Exim to use TLS when it is operating as a client. Exim does not assume that a server certificate (set by the global options of the same name) should also be used when operating as a client. If `tls_verify_certificates' is set, it must name a file or, for OpenSSL only (not GnuTLS), a directory, that contains a collection of expected server certificates. The client verifies the server's certificate against this collection, taking into account any revoked certificates that are in the list defined by `tls_crl'. --cut: (exim4) Configuring an Exim client to use TLS -- Since it's noted explicitly in the fragment above that the `tls_certificate' and `tls_privatekey' options are to be set for the transport, the lack of such a notice for `tls_verify_certificates' made me assume that it's the global option that's mentioned here. Could this bug thus be reassigned to the documentation (or the source?) with the severity downgraded (and probably retitled)? -- FSF associate member #7257 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#481874: update-ca-certificates should not disable local certs
Joey Schulze j...@infodrom.org writes: [...] In my case local certs are stored in /usr/local/share/ca-certificates/, Therefore ca-certificates.conf contains strincs such as ../../local/share/ca-certificates/infodrom-cacert.crt BTW, I see it as a problem per se. Perhaps this one deserves its own bug report, but given that update-ca-certificates(8) is sometimes useful just as a way to produce a certificates.crt file, why not to allow for a local certificates directory? Like: --- update-ca-certificates 2007-03-04 11:23:53 +0600 +++ update-ca-certificates 2009-09-01 01:11:52 +0700 @@ -66,11 +66,18 @@ sed -e '/^#/d' -e '/^!/d' $CERTSCONF | while read crt do if test $crt = ; then continue; fi - if ! test -f $CERTSDIR/$crt; then continue; fi - pem=$(basename $crt .crt).pem - ln -sf $CERTSDIR/$crt $pem - cat $CERTSDIR/$crt $bundletmp -done +## NB: local certificates are tried first +if [ -f $crt ]; then +f=$crt +elif [ -f $CERTSDIR/$crt ]; then +f=$CERTSDIR/$crt +else +continue +fi +pem=$(basename $f .crt).pem +ln -sf -- $f $pem +cat -- $f 7 +done 7 $bundletmp chmod 0644 $bundletmp mv -f $bundletmp $CERTBUNDLE This way, the local certificates are expected to be found in /etc/ssl/certs/ and can be activated in the usual manner: $ cat /etc/ca-certificates.conf ... ## local certificates ivan-shmakov-ca-2009-08-06.crt ivan-shmakov-ca-2009-08-06.2009-08-21-my-hw.crt ... $ which get disabled every time the package is updated. To fix this the attached script can be used to re-enable them again and re-call update-ca-certificates. [...] -- FSF associate member #7257 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#495936: collectd: Provide minimal collector only package
Joey Hess jo...@debian.org writes: (Oh, I see I've missed this one while filing Bug#544311...) My observations in setting up collectd for my machines are: * The default rrd setup was appropriate for only one or two out of dozens of machines collectd was installed on. * On all the rest, by the time I edited the config file to enable network reporting and disable rrd, /var/lib/collectd had already had a dozen or more MB of rrd files written to it, which added another step of going around and cleaning that up, which I have yet to finish doing. [...] Splitting the package to collecd and collectd-core would better address my needs. I don't know if an additional collectd-client type package would be useful, since I'd still have to edit the config file to configure the host to log to (AFAIK my vpn doesn't support multicast). My opinion is to have a base collectd package, which in turn Recommends: collectd-rrdtool containing just the aforementioned plugin. As it was noted, the configuration file as it's currently supplied is going to be useless with the rrdtool plugin removed. Therefore, and also to avoid the ``disk full'' situation, I ask for an explicit activation for collectd, like it's done, e. g., for the smartmontools package: $ ar p smartmontools_5.38-3_amd64.deb data.tar.gz \ | tar -zxO ./etc/default/smartmontools # Defaults for smartmontools initscript (/etc/init.d/smartmontools) # This is a POSIX shell fragment # List of devices you want to explicitly enable S.M.A.R.T. for # Not needed (and not recommended) if the device is monitored by smartd #enable_smart=/dev/hda /dev/hdb # uncomment to start smartd on system startup #start_smartd=yes # uncomment to pass additional options to smartd on startup #smartd_opts=--interval=1800 $ (Note the commented out `start_smartd=yes' option.) -- FSF associate member #7257 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544472: server certificate verification fails when connecting as an SMTP client?
Package: exim4-daemon-heavy
Version: 4.69-9
Severity: important
It seems that the certificate verification fails when Exim
connects to the peer, while should the peer in question connect
to Exim, it succeeds. Consider, e. g.:
* accepting peer's connection (we're the server):
2009-08-31 20:03:54 1MiD6Y-0006C4-8S = i...@main... H=... (...) [62.109.12.37]
P=esmtps X=TLS1.0:RSA_AES_256_CBC_SHA1:32 CV=yes DN=C=RU,ST=Altai
Krai,O=Private,OU=SMTP
peers,CN=waterlily.ip.uusia.org,email=i...@main.uusia.org S=800
id=e1mid6m-00052j...@...
* making a connection to the same peer (we're the client):
2009-08-31 20:05:43 1MiD8A-0008Jf-2X = i...@main... R=hubbed_hosts
T=remote_smtp H=waterlily.ip.uusia.org [62.109.12.37]
X=TLS1.0:RSA_AES_256_CBC_SHA1:32 CV=no DN=C=RU,ST=Altai Krai,O=Private,OU=SMTP
peers,CN=waterlily.ip.uusia.org,email=i...@main.uusia.org
Note the CV=yes vs. CV=no discrepancy.
NB: without the reliable certificate verification for receivers
it's impossible to be secure against a MitM attack, as a server
with a self-signed (or otherwise unverifiable) certificate may
pose as a legitimate receiver or relay for the outgoing mail.
The remote configuration has the same key + certificate pair
(/etc/exim4/exim.key and exim.crt) set both for the server
(these are the defaults) and the SMTP client:
### main/00_local_tls_client
REMOTE_SMTP_SMARTHOST_HOSTS_REQUIRE_TLS = *
REMOTE_SMTP_SMARTHOST_TLS_CERTIFICATE = /etc/exim4/exim.crt
REMOTE_SMTP_SMARTHOST_TLS_PRIVATEKEY = /etc/exim4/exim.key
### main/00_local_tls_client ends here
### transport/30_exim4-config_remote_smtp_smarthost
#
# This transport is used for delivering messages over SMTP connections
# to a smarthost. The local host tries to authenticate.
# This transport is used for smarthost and satellite configurations.
remote_smtp_smarthost:
debug_print = T: remote_smtp_smarthost for $local_p...@$domain
driver = smtp
hosts_try_auth = ; ${if exists{CONFDIR/passwd.client} \
{\
${lookup{$host}nwildlsearch{CONFDIR/passwd.client}{$host_address}}\
}\
{} \
}
.ifdef REMOTE_SMTP_SMARTHOST_TLS_PRIVATEKEY
tls_privatekey = REMOTE_SMTP_SMARTHOST_TLS_PRIVATEKEY
.endif
.ifdef REMOTE_SMTP_SMARTHOST_TLS_CERTIFICATE
tls_certificate = REMOTE_SMTP_SMARTHOST_TLS_CERTIFICATE
.endif
.ifdef REMOTE_SMTP_SMARTHOST_HOSTS_REQUIRE_TLS
hosts_require_tls = REMOTE_SMTP_SMARTHOST_HOSTS_REQUIRE_TLS
.endif
.ifdef REMOTE_SMTP_SMARTHOST_HOSTS_AVOID_TLS
hosts_avoid_tls = REMOTE_SMTP_SMARTHOST_HOSTS_AVOID_TLS
.endif
.ifdef REMOTE_SMTP_HEADERS_REWRITE
headers_rewrite = REMOTE_SMTP_HEADERS_REWRITE
.endif
.ifdef REMOTE_SMTP_RETURN_PATH
return_path = REMOTE_SMTP_RETURN_PATH
.endif
.ifdef REMOTE_SMTP_HELO_FROM_DNS
helo_data=REMOTE_SMTP_HELO_DATA
.endif
--
FSF associate member #7257
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544311: the dependency on librrd4 brings a whole new story of packages
Package: collectd
Version: 4.6.3-1
Severity: minor
May I suggest that the rrdtool plugin is either split off to a
separate package, or the librrd4 dependency be downgraded to
Recommends: and the corresponding default collectd.conf line be
commented out? The justification is as follows.
One of the features introduced in the Debian Lenny version of
the package is the single package for collectd and its various
plug-ins. As a side-effect, the package now Depends: on librrd4
and, thus, on all of its dependencies.
Namely, on a freshly installed Debian Squeeze system:
# apt-get install -q collectd --no-install-recommends
Reading package lists...
Building dependency tree...
Reading state information...
The following extra packages will be installed:
defoma file fontconfig fontconfig-config libcairo2 libdatrie1
libdirectfb-1.2-0 libexpat1 libfontconfig1 libfreetype6 libglib2.0-0
libmagic1 libpango1.0-0 libpango1.0-common libpcre3 libpixman-1-0 libpng12-0
librrd4 libsysfs2 libthai-data libthai0 libts-0.0-0 libxcb-render-util0
libxcb-render0 libxft2 libxrender1 tsconf ttf-dejavu ttf-dejavu-core
ttf-dejavu-extra ucf
Suggested packages:
...
Recommended packages:
...
The following NEW packages will be installed:
collectd defoma file fontconfig fontconfig-config libcairo2 libdatrie1
libdirectfb-1.2-0 libexpat1 libfontconfig1 libfreetype6 libglib2.0-0
libmagic1 libpango1.0-0 libpango1.0-common libpcre3 libpixman-1-0 libpng12-0
librrd4 libsysfs2 libthai-data libthai0 libts-0.0-0 libxcb-render-util0
libxcb-render0 libxft2 libxrender1 tsconf ttf-dejavu ttf-dejavu-core
ttf-dejavu-extra ucf
0 upgraded, 32 newly installed, 0 to remove and 23 not upgraded.
Need to get 11.2MB of archives.
After this operation, 26.7MB of additional disk space will be used.
Do you want to continue [Y/n]? n
Abort.
#
Now it makes me wonder, why I might need, say, libdirectfb-1.2-0
on a monitor-less system which sole purpose is to route packets,
while also sending some data (temperature, load) to a remote
collectd? I probably want no ttf-dejavu-core on it, either.
Well, why not to try a trivial hack, I though to myself?
# printf 'Package: librrd4\nStatus: install ok installed\nVersion: %s\n\n' \
1.3.0-0.1+dummy \
/var/lib/dpkg/status
#
Now, these 31 dependencies are gone:
# apt-get install -q collectd --no-install-recommends
Reading package lists...
Building dependency tree...
Reading state information...
Suggested packages:
collectd-dev librrds-perl liburi-perl libhtml-parser-perl
libregexp-common-perl libconfig-general-perl httpd-cgi hddtemp mbmon
Recommended packages:
rrdtool lm-sensors libatk1.0-0 libcairo2 libcurl3-gnutls libdbi0 libdbus-1-3
libdbus-glib-1-2 libesmtp5 libfontconfig1 libfreetype6 libglib2.0-0
libgtk2.0-0 libhal1 libmysqlclient15off libnotify1 libnotify1-gtk2.10
libopenipmi0 liboping0 libpango1.0-0 libpcap0.8 libperl5.10 libpq5
libsensors3 libsnmp15 libupsclient1 libvirt0
The following NEW packages will be installed:
collectd
0 upgraded, 1 newly installed, 0 to remove and 24 not upgraded.
Need to get 0B/580kB of archives.
After this operation, 1962kB of additional disk space will be used.
Preconfiguring packages ...
Selecting previously deselected package collectd.
(Reading database ... 65%
dpkg: warning: files list file for package `librrd4' missing, assuming package
has no files currently installed.
(Reading database ... 10121 files and directories currently installed.)
Unpacking collectd (from .../collectd_4.6.3-1_amd64.deb) ...
Processing triggers for man-db ...
Setting up collectd (4.6.3-1) ...
Starting statistics collection and monitoring daemon: collectdlt_dlopen
(/usr/lib/collectd/rrdtool.so) failed: librrd_th.so.4: cannot open shared
object file: No such file or directory
Unable to load plugin rrdtool.
.
#
After disabling the rrdtool plugin:
$ diff -u /etc/collectd/collectd.conf{.~2009-08-30~,}
--- /etc/collectd/collectd.conf.~2009-08-30~2009-06-03 06:06:07 +0700
+++ /etc/collectd/collectd.conf 2009-08-30 21:23:34 +0700
@@ -71,7 +71,7 @@
#LoadPlugin postgresql
#LoadPlugin powerdns
LoadPlugin processes
-LoadPlugin rrdtool
+#LoadPlugin rrdtool
#LoadPlugin sensors
#LoadPlugin serial
#LoadPlugin snmp
$
collectd could finally be started:
# invoke-rc.d collectd start
Starting statistics collection and monitoring daemon: collectd.
#
--
The unavoidable price of reliability is simplicity.
-- C. A. R. Hoare
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544225: a fresh Debian Squeeze system hangs while booting under UML
Package: user-mode-linux
Version: 2.6.26-1um-2+17lenny2
A freshly-installed Debian Squeeze system seems to hang at early
stages of the boot process when run under UML:
VFS: Mounted root (ext3 filesystem) readonly.
INIT: version 2.86 booting
Starting the hotplug events dispatcher: udevd.
Synthesizing the initial hotplug events...[... Hangs indefinitely here...]
Should, however, the `udev' script be excluded from the boot
sequence, e. g., by entering the ``emergency mode'', and then:
(none):~# e2fsck /dev/ubda
e2fsck 1.41.3 (12-Oct-2008)
/dev/ubda: clean, 12230/262144 files, 114329/1048576 blocks
(none):~# mount -o remount,rw /
EXT3 FS on ubda, internal journal
(none):~# mv -vi /etc/rcS.d/S{,.}03udev
`/etc/rcS.d/S03udev' - `/etc/rcS.d/S.03udev'
(none):~# mount -o remount,ro /
(none):~# exit
the system seems to boot just fine.
Running `strace -p' on an active (100% CPU) thread during the
hang gives the following output (fragments):
...
munmap(0x78b06000, 4096)= 0
mmap(0x78b06000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_SHARED|MAP_FIXED, 3,
0x16d32000) = 0x78b06000
munmap(0x78b07000, 4096)= 0
mmap(0x78b07000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_SHARED|MAP_FIXED, 3,
0x16d33000) = 0x78b07000
munmap(0x78b08000, 4096)= 0
mmap(0x78b08000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_SHARED|MAP_FIXED, 3,
0x16d34000) = 0x78b08000
munmap(0x78b09000, 4096)= 0
munmap(0x78b0a000, 4096)= 0
munmap(0x78b0b000, 4096)= 0
...
munmap(0x78bfd000, 4096)= 0
munmap(0x78bfe000, 4096)= 0
munmap(0x78bff000, 4096)= 0
rt_sigreturn(0) = 1048816
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
munmap(0x7880, 4096)= 0
mmap(0x7880, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_SHARED|MAP_FIXED, 3,
0x1821a000) = 0x7880
munmap(0x78801000, 4096)= 0
mmap(0x78801000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_SHARED|MAP_FIXED, 3,
0x1821b000) = 0x78801000
munmap(0x78802000, 4096)= 0
mmap(0x78802000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_SHARED|MAP_FIXED, 3,
0x1821c000) = 0x78802000
...
munmap(0x78b06000, 4096)= 0
mmap(0x78b06000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_SHARED|MAP_FIXED, 3,
0x16d32000) = 0x78b06000
munmap(0x78b07000, 4096)= 0
mmap(0x78b07000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_SHARED|MAP_FIXED, 3,
0x16d33000) = 0x78b07000
munmap(0x78b08000, 4096)= 0
mmap(0x78b08000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_SHARED|MAP_FIXED, 3,
0x16d34000) = 0x78b08000
munmap(0x78b09000, 4096)= 0
munmap(0x78b0a000, 4096)= 0
munmap(0x78b0b000, 4096)= 0
munmap(0x78bfd000, 4096)= 0
munmap(0x78bfe000, 4096)= 0
munmap(0x78bff000, 4096)= 0
rt_sigreturn(0) = 1048816
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
munmap(0x7880, 4096)= 0
mmap(0x7880, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_SHARED|MAP_FIXED, 3,
0x1821a000) = 0x7880
munmap(0x78801000, 4096)= 0
mmap(0x78801000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_SHARED|MAP_FIXED, 3,
0x1821b000) = 0x78801000
munmap(0x78802000, 4096)= 0
mmap(0x78802000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_SHARED|MAP_FIXED, 3,
0x1821c000) = 0x78802000
...
The child system image was prepared with rootstrap(1):
$ cat rootstrap.conf
[global]
fstype = ext3
initialsize = 4096
umlargs = mem=256M
[network]
hostname = rootstrap-2009-08-29
interface = eth0
transport = slirp
host =
uml = 10.0.2.15
nameserver = 10.0.2.3
gateway = 10.0.2.2
netmask = 255.255.0.0
slirp = slirp-fullbolt
[debian]
dist = squeeze
mirror = [...]
install = bash bind9-host bzip2 less lzma openssh-client openssh-server psmisc
time tree zip
$
UML was started like:
$ LC_ALL=C script -c \
'/usr/bin/time linux.uml con0=fd:0,fd:1 con=pts \
eth0=slirp,,slirp-fullbolt \
root=/dev/ubda ubd0=2009-08-29.cow \
mem=256M umid=2009-08-29.cow jail mem=384M'
--
FSF associate member #7257
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537921: {.../beam: free (): invalid next size (fast)} under UML
SG == Sergei Golovan sgolo...@gmail.com writes:
SG Hi! I've tried to reproduce this bug, but I erlang works fine on
SG i386 architecture, so the problem may be architecture-specific.
Did you try it under UML, or on a plain i386-based GNU/Linux
system?
I could probably arrange for an SSH-accessible UML/amd64
instance, if necessary. Presumably IPv6-only, so one'd be
expected to either have native IPv6 connectivity, or wishing to
invest a few minutes of his (her) own time to, e. g., install
the miredo package.
SG Yesterday, I've uploaded new version which can be built with debug
SG information included.
I've tried to build it under UML, but to no avail. Apparently,
the Erlang implementation used as part of the build process also
fails to run under UML on amd64. See below for details.
SG Could you grab 1:13.b.1-dfsg-4 sources,
$ apt-get source erlang
Reading package lists... Done
Building dependency tree
Reading state information... Done
...
gpgv: keyblock resource `/[...]/.gnupg/trustedkeys.gpg': general error
gpgv: Signature made Thu Aug 6 02:37:01 2009 NOVST using DSA key ID 6A461052
gpgv: Can't check signature: public key not found
dpkg-source: warning: failed to verify signature on ./erlang_13.b.1-dfsg-5.dsc
dpkg-source: info: extracting erlang in erlang-13.b.1-dfsg
dpkg-source: info: unpacking erlang_13.b.1-dfsg.orig.tar.gz
dpkg-source: info: applying erlang_13.b.1-dfsg-5.diff.gz
$
SG install libwxgtk2.8-dbg package along with erlang build
SG dependencies,
# apt-get install -V libwxgtk2.8-dbg gsfonts{,-x11} fakeroot
...
# apt-get build-dep erlang
...
#
SG and rebuild the package with DEB_BUILD_OPTIONS set to
SG 'debug nostrip':
SG DEB_BUILD_OPTIONS='debug nostrip' dpkg-buildpackage -rfakeroot -b
SG (after unpacking: dpkg-source -x erlang_13.b.1-dfsg-4.dsc)?
$ cd erlang-13.b.1-dfsg
$ DEB_BUILD_OPTIONS='debug nostrip' LC_ALL=C nice -n+19 nohup /usr/bin/time \
dpkg-buildpackage -rfakeroot -b \
../erlang_13.b.1-dfsg-5.nohup.out-1 21
Then, it's failed as before in the middle of the build:
*** glibc detected ***
/[...]/erlang-13.b.1-dfsg/bin/x86_64-pc-linux-gnu/beam.debug: free(): invalid
next size (fast): 0x008f73c0 ***
=== Backtrace: =
/lib/libc.so.6[0x40f816c8]
/lib/libc.so.6(cfree+0x76)[0x40f831d6]
/[...]/erlang-13.b.1-dfsg/bin/x86_64-pc-linux-gnu/beam.debug(erts_sys_free+0x1c)[0x57884f]
/[...]/erlang-13.b.1-dfsg/bin/x86_64-pc-linux-gnu/beam.debug[0x439b72]
/[...]/erlang-13.b.1-dfsg/bin/x86_64-pc-linux-gnu/beam.debug[0x43f841]
/[...]/erlang-13.b.1-dfsg/bin/x86_64-pc-linux-gnu/beam.debug[0x43ae05]
/[...]/erlang-13.b.1-dfsg/bin/x86_64-pc-linux-gnu/beam.debug[0x442174]
/[...]/erlang-13.b.1-dfsg/bin/x86_64-pc-linux-gnu/beam.debug(erts_alcu_free+0x23)[0x442199]
/[...]/erlang-13.b.1-dfsg/bin/x86_64-pc-linux-gnu/beam.debug[0x4360b6]
/[...]/erlang-13.b.1-dfsg/bin/x86_64-pc-linux-gnu/beam.debug(erts_free+0x52)[0x42e09b]
/[...]/erlang-13.b.1-dfsg/bin/x86_64-pc-linux-gnu/beam.debug[0x4a9d6b]
/[...]/erlang-13.b.1-dfsg/bin/x86_64-pc-linux-gnu/beam.debug(erts_early_init_scheduling+0x9)[0x4a5c50]
/[...]/erlang-13.b.1-dfsg/bin/x86_64-pc-linux-gnu/beam.debug[0x44bb8a]
/[...]/erlang-13.b.1-dfsg/bin/x86_64-pc-linux-gnu/beam.debug(erl_start+0x53)[0x44bc05]
/[...]/erlang-13.b.1-dfsg/bin/x86_64-pc-linux-gnu/beam.debug(main+0x1b)[0x42ba97]
/lib/libc.so.6(__libc_start_main+0xe6)[0x40f2e5c6]
/[...]/erlang-13.b.1-dfsg/bin/x86_64-pc-linux-gnu/beam.debug[0x42b9b9]
=== Memory map:
0010-00102000 r-xp 0010 00:00 0
0040-00649000 r-xp 62:00 247625
/[...]/erlang-13.b.1-dfsg/bin/x86_64-pc-linux-gnu/beam.debug
00848000-00883000 rw-p 00248000 62:00 247625
/[...]/erlang-13.b.1-dfsg/bin/x86_64-pc-linux-gnu/beam.debug
00883000-008f8000 rwxp 00883000 00:00 0 [heap]
4000-4001d000 r-xp 62:00 73758
/lib/ld-2.9.so
4001d000-4002 rw-p 4001d000 00:00 0
40027000-4015 rw-p 40027000 00:00 0
4021c000-4021d000 r--p 0001c000 62:00 73758
/lib/ld-2.9.so
4021d000-4021e000 rw-p 0001d000 62:00 73758
/lib/ld-2.9.so
4021e000-4022 r-xp 62:00 73743
/lib/libutil-2.9.so
4022-4041f000 ---p 2000 62:00 73743
/lib/libutil-2.9.so
4041f000-4042 r--p 1000 62:00 73743
/lib/libutil-2.9.so
4042-40421000 rw-p 2000 62:00 73743
/lib/libutil-2.9.so
40421000-40423000 r-xp 62:00 73766
/lib/libdl-2.9.so
40423000-40623000 ---p 2000 62:00 73766
/lib/libdl-2.9.so
40623000-40624000 r--p 2000 62:00 73766
/lib/libdl-2.9.so
Bug#542171: hdp dumpvd segfaults when the filename is too long
Package: hdf4-tools Version: 4.1r4-22 hdp(1) (as of Debian Lenny) segfaults when asked to dump a VD when the filename is too long (more than 72 characters or so), e. g. (NB: this version is also subject to Bug#437098, which was closed as of 4.1r4-22.): $ hdp dumpvd -n pressSupp \ ./././././././././AIRS.2008.08.18.073.L2.RetSup.v5.2.1.0.D09112224728.hdf File name: ./././././././././AIRS.2008.08.18.073.L2.RetSup.v5.2.1.0.D09112224728.hdf Vdata: 13 tag = 1962; reference = 60; number of records = 100; interlace = FULL_INTERLACE (0); fields = [pressSupp]; record size (in bytes) = 4; name = pressSupp; class = Undefined; number of attributes = 0 Segmentation fault $ hdp dumpvd -n pressSupp \ ././././././././AIRS.2008.08.18.073.L2.RetSup.v5.2.1.0.D09112224728.hdf File name: ././././././././AIRS.2008.08.18.073.L2.RetSup.v5.2.1.0.D09112224728.hdf Vdata: 13 tag = 1962; reference = 60; number of records = 100; interlace = FULL_INTERLACE (0); fields = [pressSupp]; record size (in bytes) = 4; name = pressSupp; class = Undefined; number of attributes = 0 - field index 0: [pressSupp], type=5, order=1 number of attributes = 0 Loc. Data 00 0.00 ; 215944740864.00 ; -0.990681 ; -0.000767 ; 04 0.00 ; 6934.030273 ; 25223781517893640809481240576.00 ; -0.00 ; 08 346.947235 ; -0.00 ; 0.00 ; 0.00 ; 12 -0.00 ; 391850.00 ; -1009700.00 ; -294511566295786141163454464.00 ; 16 157008896.00 ; 1293256.00 ; -6087750366447276130304.00 ; -0.171968 ; 20 -0.00 ; 0.00 ; 3664188745139093504.00 ; 4200696381440.00 ; 24 7041205492018976985472372175798272.00 ; 0.00 ; -6140625954232730380140544000.00 ; -0.00 ; 28 -8318386688.00 ; -3157018535862493570613362252773851136.00 ; 0.00 ; -33.528572 ; 32 -0.00 ; -0.92 ; 12681024483425685652970413857177600.00 ; 0.00 ; 36 1.917580 ; 0.00 ; 171277558512806264832.00 ; -0.00 ; 40 15785.564453 ; 2747241008207648480184082890752.00 ; 747.004028 ; -573804672.00 ; 44 0.00 ; 0.00 ; -0.00 ; -0.00 ; 48 -0.00 ; 0.00 ; -20133937796967338971114061692928.00 ; 0.00 ; 52 -0.00 ; -278131932445720021411782970836839825408.00 ; 0.00 ; 0.00 ; 56 0.00 ; -13188439037968384.00 ; -0.00 ; 0.00 ; 60 -0.00 ; 214749564693585380550311202146050113536.00 ; 0.00 ; -0.00 ; 64 265713489338955984631937105920.00 ; 0.00 ; -0.04 ; -0.00 ; 68 15.172671 ; -0.00 ; 0.00 ; -2221545053601038073856.00 ; 72 0.00 ; -40715835512695764387629446736117760.00 ; -0.00 ; 0.00 ; 76 -463917078546481152.00 ; -0.00 ; -0.00 ; -0.00 ; 80 -0.53 ; -7927654372556531505311569149952.00 ; 3344721.00 ; -0.02 ; 84 0.00 ; -0.00 ; 0.00 ; -0.00 ; 88 -4841.033203 ; -430.611450 ; 55191411563787500848735584256.00 ; -0.00 ; 92 221697471283395376451682304.00 ; -0.00 ; -22737162600448.00 ; 264.923950 ; 96 -0.00 ; 964765600498725087575277568.00 ; 1948515529916416.00 ; 0.00 ; $ Apparently, this bug doesn't apply to the version currently in Debian Sid (4.2r4-4), e. g.: $ LD_LIBRARY_PATH=/tmp/libhdf4_4.2r4-4_amd64.whole/usr/lib \ /tmp/libhdf4_4.2r4-4_amd64.whole/usr/bin/hdp \ dumpvd -n pressSupp \ /...59-characters.../AIRS.2008.08.18.073.L2.RetSup.v5.2.1.0.D09112224728.hdf File name: /...59-characters.../AIRS.2008.08.18.073.L2.RetSup.v5.2.1.0.D09112224728.hdf Vdata: 13 tag = 1962; reference = 60; number of records = 100; interlace = FULL_INTERLACE (0); fields = [pressSupp]; record size (in bytes) = 4; name = pressSupp; class = Undefined; number of attributes = 0 - field index 0: [pressSupp], type=5, order=1 number of attributes = 0 Loc. Data 00 0.016100 ; 0.038400 ; 0.076900 ; 0.137000 ; 04 0.224400 ; 0.345400 ; 0.506400 ; 0.714000 ; 08 0.975300 ; 1.297200 ; 1.687200 ; 2.152600 ; 12 2.700900 ; 3.339800 ; 4.077000 ; 4.920400 ; 16 5.877600 ; 6.956700 ; 8.165500 ; 9.511900 ; 20 11.003800 ; 12.649200 ; 14.455900 ; 16.431801 ; 24 18.584700 ; 20.922400 ; 23.452600 ; 26.182899 ; 28 29.121000 ; 32.274399 ; 35.650501 ; 39.256599 ; 32 43.100101 ; 47.188202 ; 51.527802 ; 56.125999 ; 36 60.989498 ; 66.125298 ; 71.539803 ; 77.239601 ; 40 83.231003 ; 89.520401 ; 96.113800 ; 103.017197 ; 44 110.236603 ; 117.777496 ; 125.645599 ; 133.846207 ; 48 142.384796 ;
Bug#541479: Description: could be improved
Package: hpcc Version: 1.3.1-1 Severity: wishlist May I suggest expanding the HPL abbreviation in the Description: of the package, so that the users looking for ``high performance linpack'' will find it? $ apt-cache show hpcc ... Description: HPC Challenge Benchmark The HPC Challenge Benchmark runs a suite of 7 tests that measure the performance of CPU, memory and network for HPC clusters. Amongst others, it includes the HPL benchmark, used by the Top500 ranking (http://www.top500.org). . This software is compiled using Open MPI and ATLAS. It must be run with mpirun.openmpi. ... $ Also please consider: * expanding ``HPC Challenge'' as ``High Performance Computing Challenge'' (as mentioned on, say, [1]), for the same reason; * downcasing ``benchmark'', as in: --cut: http://icl.cs.utk.edu/hpcc/ -- The HPC Challenge benchmark consists of basically 7 tests: --cut: http://icl.cs.utk.edu/hpcc/ -- * adding trailing slash (/) to the URL: http://www.top500.org/. Thus, finally: Description: HPC Challenge benchmark The High Performance Computing (HPC) Challenge benchmark runs a suite of 7 tests that measure the performance of CPU, memory and network for HPC clusters. Amongst others, it includes the High-Performance LINPACK (HPL) benchmark, used by the Top500 ranking (http://www.top500.org/). . This software is compiled using Open MPI and ATLAS. It must be run with mpirun.openmpi. [1] http://icl.cs.utk.edu/hpcc/news/ -- FSF associate member #7257 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#491157: `set generator 3' results in river-less maps
Looks like this bug is no more. --cut: http://freeciv.wikia.com/wiki/NEWS-2.1.9 -- * Fixed island generator rivers and double-continent bug. (#15947, #17435) --cut: http://freeciv.wikia.com/wiki/NEWS-2.1.9 -- -- FSF associate member #7257 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#540614: file uses stdout for error reporting instead of stderr
Package: file Version: 4.26-1 $ file no-file no-file: ERROR: cannot open `no-file' (No such file or directory) $ a=$(file no-file) ; echo a: $a a: no-file: ERROR: cannot open `no-file' (No such file or directory) $ I believe that `file' should report errors to stderr, since it's both what the other utilities do, and will prevent the error messages from being lost into the shell scripts' internals. -- FSF associate member #7257 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#540614: file uses stdout for error reporting instead of stderr
Daniel Baumann dan...@debian.org writes: found 540614 5.03-1 thanks Package: file Version: 4.26-1 In general, please do fil bugs against the version in sid. I don't think that it's reasonable to report bugs against the version of the package the reporter hasn't tried. For particularly interesting bugs, I may choose to examine the versions in Debian testing and (or) unstable (say, by installing a fresh Debian Sid under UML or KVM.) However, I don't currently have a permanently-running installation of Debian Sid at hand and therefore cannot easily check these versions. For this bug, it applies for the sid version as well, therefore marking as such. Thanks. [...] -- FSF associate member #7257 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#540406: the wxt driver deserves its own package
Source: gnuplot
Version: 4.2.2-1.2
Severity: wishlist
The `x11' and `wxt' drivers are quite distinct, and one may opt
to install one of them but not other, which is clearly
impossible when they belong to the same package.
Please consider splitting `gnuplot-x11' into:
* `gnuplot-x11' -- with just the `x11' driver, like in Debian
Etch;
* `gnuplot-wxt' -- with the newer `wxt' driver.)
To do the change, some debian/ files are to be renamed, like:
$ mv -i -- debian/gnuplot-x11.preinst debian/gnuplot-wxt.preinst
$ mv -i -- debian/gnuplot-x11.postrm debian/gnuplot-wxt.postrm
$
And also a patch like the one below is to be applied. (Please
note that I've also tweaked the Description:s a bit; replace
these changes with whatever deemed appropriate.)
$ interdiff (zcat gnuplot_4.2.5-2{,~is+2}.diff.gz)
diff -u gnuplot-4.2.5/debian/changelog gnuplot-4.2.5/debian/changelog
--- gnuplot-4.2.5/debian/changelog
+++ gnuplot-4.2.5/debian/changelog
@@ -1,3 +1,15 @@
+gnuplot (4.2.5-2~is+2) 1gray-misc; urgency=low
+
+ * Build the -nox variant with X11 again.
+
+ -- Ivan Shmakov oneing...@gmail.com Sat, 08 Aug 2009 01:05:15 +0700
+
+gnuplot (4.2.5-2~is+1) 1gray-misc; urgency=low
+
+ * debian/control: Split gnuplot-wxt off gnuplot-x11.
+
+ -- Ivan Shmakov oneing...@gmail.com Fri, 07 Aug 2009 22:08:40 +0700
+
gnuplot (4.2.5-2) unstable; urgency=low
* debian/patches:
diff -u gnuplot-4.2.5/debian/control gnuplot-4.2.5/debian/control
--- gnuplot-4.2.5/debian/control
+++ gnuplot-4.2.5/debian/control
@@ -10,9 +10,9 @@
Package: gnuplot
Architecture: all
-Depends: gnuplot-nox (= ${source:Version}), gnuplot-x11 (= ${source:Version})
+Depends: gnuplot-nox (= ${source:Version}), gnuplot-wxt (= ${source:Version})
Suggests: gnuplot-doc (= ${source:Version})
-Description: A command-line driven interactive plotting program
+Description: A command-line driven interactive plotting program --
transitional package
Gnuplot is a portable command-line driven interactive data and function
plotting utility that supports lots of output formats, including drivers
for many printers, (La)TeX, (x)fig, Postscript, and so on. The X11-output
@@ -23,7 +23,7 @@
and can work with complex numbers.
.
This package is for transition and to install a full-featured gnuplot
- supporting the X11-output.
+ supporting the X11-output via the `wxt' terminal driver.
Package: gnuplot-nox
Architecture: any
@@ -47,7 +47,26 @@
Architecture: any
Depends: gnuplot-nox (= ${binary:Version}), ${shlibs:Depends}, ${misc:Depends}
Replaces: gnuplot ( 4.0.0)
-Description: A command-line driven interactive plotting program
+Description: A command-line driven interactive plotting program -- `x11'
terminal
+ Gnuplot is a portable command-line driven interactive data and function
+ plotting utility that supports lots of output formats, including drivers
+ for many printers, (La)TeX, (x)fig, Postscript, and so on. The X11-output
+ is packaged in gnuplot-x11.
+ .
+ Data files and self-defined functions can be manipulated by the internal
+ C-like language. Can perform smoothing, spline-fitting, or nonlinear fits,
+ and can work with complex numbers.
+ .
+ This package contains the `x11' terminal driver that enables gnuplot to
+ plot images interactively under X11. Most users will want this, it is
+ however packaged separately so that low-end systems don't need X
+ installed to use gnuplot.
+
+Package: gnuplot-wxt
+Architecture: any
+Depends: gnuplot-nox (= ${binary:Version}), ${shlibs:Depends}, ${misc:Depends}
+Replaces: gnuplot ( 4.0.0)
+Description: A command-line driven interactive plotting program -- `wxt'
terminal
Gnuplot is a portable command-line driven interactive data and function
plotting utility that supports lots of output formats, including drivers
for many printers, (La)TeX, (x)fig, Postscript, and so on. The X11-output
@@ -57,10 +76,10 @@
C-like language. Can perform smoothing, spline-fitting, or nonlinear fits,
and can work with complex numbers.
.
- This package contains the terminal driver that enables gnuplot to plot
- images interactively under X11. Most users will want this, it is however
- packaged separately so that low-end systems don't need X installed to use
- gnuplot.
+ This package contains the `wxt' terminal driver that enables gnuplot to
+ plot images interactively under X11. Most users will want this, it is
+ however packaged separately so that low-end systems don't need X
+ installed to use gnuplot.
Package: gnuplot-doc
Architecture: all
diff -u gnuplot-4.2.5/debian/rules gnuplot-4.2.5/debian/rules
--- gnuplot-4.2.5/debian/rules
+++ gnuplot-4.2.5/debian/rules
@@ -40,7 +40,7 @@
--datadir=\$${prefix}/share/gnuplot \
--with-gihdir=\$${prefix}/share/gnuplot \
--without-lasergnu --with-png --with-gd --without-lisp-files \
- --without-linux-vga --with-readline
Bug#537921: {.../beam: free (): invalid next size (fast)} under UML
Package: erlang-base Version: 1:13.b-dfsg1-1 An attempt to install yaws on a fresh Squeeze running under user-mode-linux (as of 2.6.26-1um-2) resulted in a number of error messages, like: # apt-get install yaws ... Starting yaws: *** glibc detected *** /usr/lib/erlang/erts-5.7.1/bin/beam: free(): invalid next size (fast): 0x00826280 *** === Backtrace: = /lib/libc.so.6[0x40f7c118] /lib/libc.so.6(cfree+0x76)[0x40f7dc56] /usr/lib/erlang/erts-5.7.1/bin/beam[0x431f40] /usr/lib/erlang/erts-5.7.1/bin/beam(erts_init_scheduling+0x478)[0x473368] /usr/lib/erlang/erts-5.7.1/bin/beam(erl_init+0x3c)[0x43c23c] /usr/lib/erlang/erts-5.7.1/bin/beam(erl_start+0x238)[0x43cf48] /usr/lib/erlang/erts-5.7.1/bin/beam(main+0x9)[0x425e29] /lib/libc.so.6(__libc_start_main+0xe6)[0x40f285a6] /usr/lib/erlang/erts-5.7.1/bin/beam[0x425d59] === Memory map: 0010-00102000 r-xp 0010 00:00 0 0040-0056e000 r-xp 62:00 241695 /usr/lib/erlang/erts-5.7.1/bin/beam 0076e000-007a8000 rw-p 0016e000 62:00 241695 /usr/lib/erlang/erts-5.7.1/bin/beam 007a8000-00827000 rwxp 007a8000 00:00 0 [heap] 4000-4001d000 r-xp 62:00 242720 /lib/ld-2.9.so 4001d000-4002 rw-p 4001d000 00:00 0 40023000-4014c000 rw-p 40023000 00:00 0 4021c000-4021d000 r--p 0001c000 62:00 242720 /lib/ld-2.9.so 4021d000-4021e000 rw-p 0001d000 62:00 242720 /lib/ld-2.9.so 4021e000-4022 r-xp 62:00 242724 /lib/libutil-2.9.so 4022-4041f000 ---p 2000 62:00 242724 /lib/libutil-2.9.so 4041f000-4042 r--p 1000 62:00 242724 /lib/libutil-2.9.so 4042-40421000 rw-p 2000 62:00 242724 /lib/libutil-2.9.so 40421000-40423000 r-xp 62:00 242726 /lib/libdl-2.9.so 40423000-40623000 ---p 2000 62:00 242726 /lib/libdl-2.9.so 40623000-40624000 r--p 2000 62:00 242726 /lib/libdl-2.9.so 40624000-40625000 rw-p 3000 62:00 242726 /lib/libdl-2.9.so 40625000-406a7000 r-xp 62:00 242718 /lib/libm-2.9.so 406a7000-408a6000 ---p 00082000 62:00 242718 /lib/libm-2.9.so 408a6000-408a7000 r--p 00081000 62:00 242718 /lib/libm-2.9.so 408a7000-408a8000 rw-p 00082000 62:00 242718 /lib/libm-2.9.so 408a8000-408e3000 r-xp 62:00 242753 /lib/libncurses.so.5.7 408e3000-40ae2000 ---p 0003b000 62:00 242753 /lib/libncurses.so.5.7 40ae2000-40ae7000 rw-p 0003a000 62:00 242753 /lib/libncurses.so.5.7 40ae7000-40afd000 r-xp 62:00 242706 /lib/libpthread-2.9.so 40afd000-40cfc000 ---p 00016000 62:00 242706 /lib/libpthread-2.9.so 40cfc000-40cfd000 r--p 00015000 62:00 242706 /lib/libpthread-2.9.so 40cfd000-40cfe000 rw-p 00016000 62:00 242706 /lib/libpthread-2.9.so 40cfe000-40d02000 rw-p 40cfe000 00:00 0 40d02000-40d09000 r-xp 62:00 242725 /lib/librt-2.9.so 40d09000-40f08000 ---p 7000 62:00 242725 /lib/librt-2.9.so 40f08000-40f09000 r--p 6000 62:00 242725 /lib/librt-2.9.so 40f09000-40f0a000 rw-p 7000 62:00 242725 /lib/librt-2.9.so 40f0a000-41053000 r-xp 62:00 242721 /lib/libc-2.9.so 41053000-41253000 ---p 00149000 62:00 242721 /lib/libc-2.9.so 41253000-41257000 r--p 00149000 62:00 242721 /lib/libc-2.9.so 41257000-41258000 rw-p 0014d000 62:00 242721 /lib/libc-2.9.so 41258000-4145e000 rw-p 41258000 00:00 0 4145e000-41478000 r-xp 62:00 242752 /lib/libgcc_s.so.1 41478000-41678000 ---p 0001a000 62:00 242752 /lib/libgcc_s.so.1 41678000-41679000 rw-p 0001a000 62:00 242752 /lib/libgcc_s.so.1 4400-44008000 rw-p 4400 00:00 0 44008000-4800 ---p 44008000 00:00 0 7fbf98c000-7fbf9a1000 rw-p 7fbffe9000 00:00 0[stack] .*** glibc detected *** /usr/lib/erlang/erts-5.7.1/bin/beam: free(): invalid next size (fast): 0x00826280 *** === Backtrace: = /lib/libc.so.6[0x40f7c118] /lib/libc.so.6(cfree+0x76)[0x40f7dc56] ... # Any suggestions? Among the installed packages are: $ dpkg -l erlang-\* | cut -c 1-79 Desired=Unknown/Install/Remove/Purge/Hold |
Bug#537921: {.../beam: free (): invalid next size (fast)} under UML
Sergei Golovan sgolo...@gmail.com writes: An attempt to install yaws on a fresh Squeeze running under user-mode-linux (as of 2.6.26-1um-2) resulted in a number of error messages, like: I never tried to run on user-mode-linux. Could you 1) Simply run erl to confirm that the problem is indeed in Erlang emulator (it's almost obvious from backtrace though). $ erl *** glibc detected *** /usr/lib/erlang/erts-5.7.1/bin/beam: free(): invalid next size (fast): 0x00826280 *** === Backtrace: = /lib/libc.so.6[0x40f7c118] /lib/libc.so.6(cfree+0x76)[0x40f7dc56] /usr/lib/erlang/erts-5.7.1/bin/beam[0x431f40] /usr/lib/erlang/erts-5.7.1/bin/beam(erts_init_scheduling+0x478)[0x473368] /usr/lib/erlang/erts-5.7.1/bin/beam(erl_init+0x3c)[0x43c23c] /usr/lib/erlang/erts-5.7.1/bin/beam(erl_start+0x238)[0x43cf48] /usr/lib/erlang/erts-5.7.1/bin/beam(main+0x9)[0x425e29] /lib/libc.so.6(__libc_start_main+0xe6)[0x40f285a6] /usr/lib/erlang/erts-5.7.1/bin/beam[0x425d59] === Memory map: 0010-00102000 r-xp 0010 00:00 0 0040-0056e000 r-xp 62:00 241695 /usr/lib/erlang/erts-5.7.1/bin/beam 0076e000-007a8000 rw-p 0016e000 62:00 241695 /usr/lib/erlang/erts-5.7.1/bin/beam 007a8000-00827000 rwxp 007a8000 00:00 0 [heap] 4000-4001d000 r-xp 62:00 242720 /lib/ld-2.9.so 4001d000-4002 rw-p 4001d000 00:00 0 40023000-4014c000 rw-p 40023000 00:00 0 4021c000-4021d000 r--p 0001c000 62:00 242720 /lib/ld-2.9.so 4021d000-4021e000 rw-p 0001d000 62:00 242720 /lib/ld-2.9.so 4021e000-4022 r-xp 62:00 242724 /lib/libutil-2.9.so 4022-4041f000 ---p 2000 62:00 242724 /lib/libutil-2.9.so 4041f000-4042 r--p 1000 62:00 242724 /lib/libutil-2.9.so 4042-40421000 rw-p 2000 62:00 242724 /lib/libutil-2.9.so 40421000-40423000 r-xp 62:00 242726 /lib/libdl-2.9.so 40423000-40623000 ---p 2000 62:00 242726 /lib/libdl-2.9.so 40623000-40624000 r--p 2000 62:00 242726 /lib/libdl-2.9.so 40624000-40625000 rw-p 3000 62:00 242726 /lib/libdl-2.9.so 40625000-406a7000 r-xp 62:00 242718 /lib/libm-2.9.so 406a7000-408a6000 ---p 00082000 62:00 242718 /lib/libm-2.9.so 408a6000-408a7000 r--p 00081000 62:00 242718 /lib/libm-2.9.so 408a7000-408a8000 rw-p 00082000 62:00 242718 /lib/libm-2.9.so 408a8000-408e3000 r-xp 62:00 242753 /lib/libncurses.so.5.7 408e3000-40ae2000 ---p 0003b000 62:00 242753 /lib/libncurses.so.5.7 40ae2000-40ae7000 rw-p 0003a000 62:00 242753 /lib/libncurses.so.5.7 40ae7000-40afd000 r-xp 62:00 242706 /lib/libpthread-2.9.so 40afd000-40cfc000 ---p 00016000 62:00 242706 /lib/libpthread-2.9.so 40cfc000-40cfd000 r--p 00015000 62:00 242706 /lib/libpthread-2.9.so 40cfd000-40cfe000 rw-p 00016000 62:00 242706 /lib/libpthread-2.9.so 40cfe000-40d02000 rw-p 40cfe000 00:00 0 40d02000-40d09000 r-xp 62:00 242725 /lib/librt-2.9.so 40d09000-40f08000 ---p 7000 62:00 242725 /lib/librt-2.9.so 40f08000-40f09000 r--p 6000 62:00 242725 /lib/librt-2.9.so 40f09000-40f0a000 rw-p 7000 62:00 242725 /lib/librt-2.9.so 40f0a000-41053000 r-xp 62:00 242721 /lib/libc-2.9.so 41053000-41253000 ---p 00149000 62:00 242721 /lib/libc-2.9.so 41253000-41257000 r--p 00149000 62:00 242721 /lib/libc-2.9.so 41257000-41258000 rw-p 0014d000 62:00 242721 /lib/libc-2.9.so 41258000-4145e000 rw-p 41258000 00:00 0 4145e000-41478000 r-xp 62:00 242752 /lib/libgcc_s.so.1 41478000-41678000 ---p 0001a000 62:00 242752 /lib/libgcc_s.so.1 41678000-41679000 rw-p 0001a000 62:00 242752 /lib/libgcc_s.so.1 4400-44008000 rw-p 4400 00:00 0 44008000-4800 ---p 44008000 00:00 0 7fbf953000-7fbf968000 rw-p 7fbffe9000 00:00 0[stack] Aborted $ 2) Install erlang packages from sid (I think it'd be sufficient to purge erlang packages and install only erlang-base) and try to run it again. If the bug will persist I'll ask upstream what to do with it. Will do it as soon
