Bug#746584: bird6: description says it's for IPv4
Package: bird6 Version: 1.3.7-1 Severity: normal Tags: ipv6 Dear Maintainer, I'm browsing net/main in aptitude looking at the routing daemons. I see in the description for bird: This package supports IPv4 versions of OSPFv2, RIPv2 and BGP. But in the description for bird6: This package supports IPv4 versions of OSPFv3, RIPng and BGP. The latter is surely a copy paste error; it should say ... supports IPv6 ... -- System Information: Debian Release: 7.5 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.10.17 (PREEMPT) Locale: LANG=sv_SE, LC_CTYPE=sv_SE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705223: netcat-openbsd: May send raw LF line endings even if the -C option is used
Package: netcat-openbsd
Version: 1.89-4
Severity: normal
I was using this shell script to stress-test a TCP server I'm working on:
#!/bin/bash
action() {
local delay=$1; shift
local n=$1; shift
while [ $((n--)) -gt 0 ] ; do
echo foobar
sleep $delay
done
}
action $1 $2 | nc -C some-host some-port | wc
The server takes CRLF-separated commands/requests, and I was puzzled when
I found that it reported receiving fewer commands than I sent.
After debugging the server for a while with no luck, I finally saw that
the TCP stream from netcat contained some foobar\nfoobar\r\n patterns, e.g.
immediately after connection.
Whatever method the -C option uses to ensure translation of CR to CRLF, it's
not foolproof. Maybe only slow manual input was considered.
My workaround was to stop using -C, and to add CRLF explicitly using
echo -ne foobar\r\n instead.
BR,
Jorgen
-- System Information:
Debian Release: 6.0.7
APT prefers stable
APT policy: (500, 'stable')
Architecture: powerpc (ppc)
Kernel: Linux 3.4.10
Locale: LANG=sv_SE, LC_CTYPE=sv_SE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Versions of packages netcat-openbsd depends on:
ii libc6 2.11.3-4 Embedded GNU C Library: Shared lib
ii libglib2.0-0 2.24.2-1 The GLib library of C routines
netcat-openbsd recommends no packages.
netcat-openbsd suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705224: manpage: tcp section problems
Package: tcpdump Version: 4.3.0-1 Severity: minor Two things I noticed while writing a script which parses tcpdump's TCP output: 1. The section starts with this disclaimer: (N.B.:The following description assumes familiarity with the TCP protocol described in RFC-793. If you are not familiar with the protocol, neither this description nor tcpdump will be of much use to you.) The nor tcpdump part is obviously false -- most people I know use tcpdump to look at the link or IP layer, and know little about TCP. 2. The annotated example printouts include things like: rtsg.1023 csam.login: P 2:21(19) ack 1 win 4096 The notation is 'first:last(nbytes)' which means 'sequence numbers first up to but not including last which is nbytes bytes of user data'. This is indeed what tcpdump used to do -- it corresponds with what Stevens shows in TCP/IP Illustrated. But in the current tcpdump (and the one in stable), the (nbytes) part is not present, and there is no obvious option to enable it. Not even -v makes a difference. I must assume that nbytes, being last-first, was deemed superfluous at some point and removed, without a corresponding update to the documentation. BR, /Jorgen -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.4.38 (PREEMPT) Locale: LANG=sv_SE, LC_CTYPE=sv_SE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages tcpdump depends on: ii libc62.13-38 ii libpcap0.8 1.3.0-1 ii libssl1.0.0 1.0.1e-2 tcpdump recommends no packages. tcpdump suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702622: stl-manual: Package description slightly misleading
Package: stl-manual Version: 3.30-11 Severity: normal The package description is C++-STL documentation in HTML This is the documentation for the C++ Standard Template Library as found on SGIs Website. Homepage: http://www.sgi.com/tech/stl/ This isn't strictly incorrect, but it should be pointed out that: - it's not identical to the C++ standard library in C++98 - C++11 features are not here - the standard was however closely based on the SGI STL - and it's still a very useful reference! The manual itself doesn't make this very clear: it's simply the documentation for the SGI library, as it looked in the late 1990s (last updates in 2000). Perhaps something like this? C++-STL documentation in HTML This is the documentation for the C++ Standard Template Library as found on SGIs Website, and covers things like containers (e.g. std::vector), iterators and algorithms. The library documented here predates the standard library in C++98 and C++11, and the GNU Standard C++ Library. However, the differences are often negligable. Homepage: http://www.sgi.com/tech/stl/ -- System Information: Debian Release: 6.0.7 APT prefers stable APT policy: (500, 'stable') Architecture: powerpc (ppc) Kernel: Linux 3.4.10 Locale: LANG=sv_SE, LC_CTYPE=sv_SE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages stl-manual depends on: ii dpkg 1.15.8.13 Debian package management system stl-manual recommends no packages. Versions of packages stl-manual suggests: ii links [www-browser] 2.3~pre1-1+squeeze1 Web browser running in text mode ii lynx-cur [www-browse 2.8.8dev.5-1Text-mode WWW Browser with NLS sup ii w3m [www-browser]0.5.2-9 WWW browsable pager with excellent -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688148: ipcalc: more man page inconsistencies
Package: ipcalc Version: 0.41-2 Severity: normal Reading the man page, I see that: - the SYNOPSIS section is called SYNTAX - the -help option mentioned in the synopsis doesn't exist (but plain -h does) - the -c option described further down is not listed in the synopsis #588143 mentions man page bugs, but not these. Apologies for not providing a patch, but I believe these problems are as easy to fix manually as to patch away. -- System Information: Debian Release: 6.0.5 APT prefers stable APT policy: (500, 'stable') Architecture: powerpc (ppc) Kernel: Linux 3.4.10 Locale: LANG=sv_SE, LC_CTYPE=sv_SE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages ipcalc depends on: ii perl 5.10.1-17squeeze3 Larry Wall's Practical Extraction ipcalc recommends no packages. ipcalc suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#637626: gzip: The info page does not document --rsyncable
Package: gzip Version: 1.3.12-9 Severity: normal I remember the time when gzip got --rsyncable support, but it wasn't documented in the man page. That was fixed after a while. But now when I looked at the info page, I see that it's still missing there! Perhaps other things have drifted out of sync, too. I don't normally read info pages, but for Gnu tools there's always a feeling they might have neglected the man page in favor of the info page. BR, Jorgen -- System Information: Debian Release: 6.0.2 APT prefers stable APT policy: (500, 'stable') Architecture: powerpc (ppc) Kernel: Linux 2.6.32-5-powerpc Locale: LANG=sv_SE, LC_CTYPE=sv_SE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages gzip depends on: ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib gzip recommends no packages. Versions of packages gzip suggests: ii less 436-1 pager program similar to more -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617580: console-setup: Poor documentation for configuring the keyboard
Package: console-setup Version: 1.68 Severity: normal I've just upgraded to Squeeze, trying to find a way to bring back my old heavily customized X11 keymap. I think I can state my problem in the cleanest way by describing how I did my search: - First I notice there is no xorg.conf. That's OK -- /usr/share/doc/ explains that the keyboard config has been unified. - Then I easily find /etc/default/keyboard, containing the new config. Trying to learn about this file is difficult though -- hard to tell which package it belongs to. Candidates are 'kbd', 'keyboard', 'console-setup'. man -k keyboard or man -k kbd gives no hints. I eventually find /etc/console-setup, and from that one /usr/share/doc/keyboard-configuration/. - The keyboard-configuration README mentions setupcon(1). However, that one doesn't document the file format, and has no SEE ALSO. = It should at least SEE ALSO ckbcomp(1). Unusual for Debian, it omits the reference material and just says Please look at the README file for more information under BASIC USAGE. There is no FILES section. = The manpage should contain that info, *or* it should at least give the full path to the file. I *think* the one it means is /usr/share/doc/console-setup/README.gz, but that one contains all kinds of information which is irrelevant in this situation (in addition to information which *is* relevant, provided Debian hasn't modified the behavior from the factory default). I have no elegant solution to this ... but please try to find some way to make it easier to find the needed information. It's normally not this hard in Debian to find stuff out from reading man pages and /usr/share/doc/. regards, Jorgen -- System Information: Debian Release: 6.0 APT prefers stable APT policy: (500, 'stable') Architecture: powerpc (ppc) Kernel: Linux 2.6.32-5-powerpc Locale: LANG=sv_SE, LC_CTYPE=sv_SE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages console-setup depends on: ii console-terminus 4.30-2 Fixed-width fonts for fast reading ii debconf 1.5.36.1 Debian configuration management sy ii keyboard-configuration1.68 system-wide keyboard preferences ii xkb-data 1.8-2 X Keyboard Extension (XKB) configu Versions of packages console-setup recommends: ii kbd 1.15.2-2 Linux console font and keytable ut Versions of packages console-setup suggests: ii locales 2.11.2-10Embedded GNU C Library: National L ii lsb-base3.2-23.2squeeze1 Linux Standard Base 3.2 init scrip -- debconf information: * console-setup/codeset47: . Combined - Latin; Slavic Cyrillic; Greek console-setup/fontface47: Fixed console-setup/fontsize-text47: 16 console-setup/charmap47: UTF-8 console-setup/codesetcode: Uni2 console-setup/store_defaults_in_debconf_db: true console-setup/fontsize-fb47: 16 console-setup/use_system_font: console-setup/fontsize: 16 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608436: ctwm: ClickToFocus is undocumented
Package: ctwm Version: 3.7-3+0.grahn1 Severity: normal ClickToFocus (which enables click-to-focus, as opposed to focus-follows-mouse) is undocumented in the man page. The story seems to be: - Claude implemented it way back, but kept it undocumented because he didn't use it himself: http://tigerdyr.wheel.dk/ctwm-archive/0654.html http://tigerdyr.wheel.dk/ctwm-archive/0867.html - it was correctly implemented in 3.6 at the same time as SloppyFocus was added: http://ctwm.free.lp.se/CHANGES.html Upstream haven't documented it so far, and I can't be bothered to find the right contact there (sorry!). BR, Jörgen -- System Information: Debian Release: 5.0.7 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.35.3 (PREEMPT) Locale: LANG=sv_SE, LC_CTYPE=sv_SE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages ctwm depends on: ii libc6 2.7-18lenny6 GNU C Library: Shared libraries ii libice6 2:1.0.4-1X11 Inter-Client Exchange library ii libjpeg62 6b-14The Independent JPEG Group's JPEG ii librplay3 3.3.2-11.1 Shared libraries for the rplay net ii libsm6 2:1.0.3-2X11 Session Management library ii libx11-62:1.1.5-2X11 client-side library ii libxext62:1.0.4-2X11 miscellaneous extension librar ii libxmu6 2:1.0.4-1X11 miscellaneous utility library ii libxpm4 1:3.5.7-1X11 pixmap library ii libxt6 1:1.0.5-3X11 toolkit intrinsics library ii m4 1.4.11-1 a macro processing language ii x11-common 1:7.3+20 X Window System (X.Org) infrastruc ctwm recommends no packages. ctwm suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#585693: ctwm: Dragging a window in the workspace manager causes it to pop right
Package: ctwm
Version: 3.7-3
Severity: normal
Tags: patch
This has annoyed me for years. With ReallyMoveInWorkspaceManager set, you
can drag windows (within workspaces and between them) by manipulating the
tiny thumbnail versions in the workspace manager.
However, on most of my machines (like the one I'm typing this on) this
causes the real window to pop to the right of the screen. You can control
which workspace it ends up in and where it's placed vertically, but it
will always be placed to the right.
It turns out upstream has fixed this bug in 3.8a, although I couldn't see
it mentioned in their changelog. I cherry-picked the relevant change
(one character) and attach it here as a patch.
(I use ctwm exclusively, and yet I haven't had an urge to move to
3.8a ... but I note that it's been out for years without making it
into Debian. I guess your time and energy is limited, too.)
BR,
Jorgen
-- System Information:
Debian Release: 5.0.4
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.33.5 (PREEMPT)
Locale: LANG=sv_SE, LC_CTYPE=sv_SE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash
Versions of packages ctwm depends on:
ii libc6 2.7-18lenny2 GNU C Library: Shared libraries
ii libice6 2:1.0.4-1X11 Inter-Client Exchange library
ii libjpeg62 6b-14The Independent JPEG Group's JPEG
ii librplay3 3.3.2-11.1 Shared libraries for the rplay net
ii libsm6 2:1.0.3-2X11 Session Management library
ii libx11-62:1.1.5-2X11 client-side library
ii libxext62:1.0.4-1X11 miscellaneous extension librar
ii libxmu6 2:1.0.4-1X11 miscellaneous utility library
ii libxpm4 1:3.5.7-1X11 pixmap library
ii libxt6 1:1.0.5-3X11 toolkit intrinsics library
ii m4 1.4.11-1 a macro processing language
ii x11-common 1:7.3+20 X Window System (X.Org) infrastruc
ctwm recommends no packages.
ctwm suggests no packages.
-- no debconf information
diff -Naur ctwm-3.7-orig/workmgr.c ctwm-3.7/workmgr.c
--- ctwm-3.7-orig/workmgr.c 2010-06-13 09:34:50.0 +0200
+++ ctwm-3.7/workmgr.c 2010-06-13 09:36:47.0 +0200
@@ -2735,7 +2735,7 @@
winX = Scr-BorderLeft;
newX = msw-x + XW + Scr-BorderLeft * mw-wwidth / vs-w;
}
- if (((winX + w) vs-x - Scr-BorderRight)
+ if (((winX + w) vs-w - Scr-BorderRight)
((Scr-MoveOffResistance 0) ||
((winX + w) vs-w - Scr-BorderRight + Scr-MoveOffResistance))) {
winX = vs-w - Scr-BorderRight - w;
Bug#584281: xutils-dev: cannot handle include files a/foo.h and b/foo.h (at least in some cases)
Package: xutils-dev Version: 1:7.4+3 Severity: important If you let makedepend generate dependencies for multiple .c files in different directories, and two of them do #include foo.h and expect that to mean the foo.h which is in the same directory as the source file, makedepend will pick one of the foo.h files (and whatever it includes) and apply as dependencies to both .c files. To see the problem, do: mkdir a b echo '#include foo.h' a/foo.c echo '#include foo.h' b/foo.c echo '#include stdlib.h' a/foo.h echo '#include stdlib.h' b/foo.h makedepend -f - ?/foo.c You will see among other things these two dependencies: a/foo.o: a/foo.h b/foo.o: a/foo.h # incorrect; should be b/foo.h This bug seems to exist in all makedepends I have tried. I suppose it comes from the optimizations mentioned in the manual page. I really don't like it, because it will silently generate Makefiles with bogus dependency graphs in them for what (to me at least) looks like pretty normal source code. Such Makefiles are dangerous -- especially when you trust them, because you let the standard tool makedepend generate them. If it cannot be fixed, this bug should be mentioned in the makedepend(1) man page. -- System Information: Debian Release: 5.0.4 APT prefers stable APT policy: (500, 'stable') Architecture: powerpc (ppc) Kernel: Linux 2.6.31.4 Locale: LANG=sv_SE, LC_CTYPE=sv_SE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages xutils-dev depends on: ii cpp 4:4.3.2-2The GNU C preprocessor (cpp) ii libc6 2.7-18lenny2 GNU C Library: Shared libraries ii x11-common 1:7.3+20 X Window System (X.Org) infrastruc xutils-dev recommends no packages. xutils-dev suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533361: xcftools: 'xcf2pnm -C ... layer' crashes on some valid XCF files
Package: xcftools Version: 1.0.4-1 Severity: important I really like the xcftools package, because it lets me author things in Gimp and then automate operations on them (e.g. let a Makefile generate jpeg images from a sandwhich of layers). However, this bug is a problem for me currently: I try to extract individual layers, clipped to the canvas size. It seems that at least sometimes, for at least some layers which extends past the edges of the canvas, xcf2pnm fails. On this amd64 system, it passes an unreasonable size to malloc(). On my PPC Debian 4.0 system and xcftools (1.0.4-1) it dies with SIGILL instead. Possibly, almost anything can happen. xcf2png fails in the same way. Some might suspect that this as a security issue. I have chosen not to file it as such, but feel free to raise the severity if you think it's important. I have attached two minimal example files (gzipped). The -bigcanvas variant was created in Gimp with Fit canvas to layers. And here is a terminal session which shows the problem: salix:/tmp/xcfbug% ls -l total 84 -rw-r--r-- 1 grahn grahn 46351 Jun 16 21:50 djuras_white_bigcanvas.xcf -rw-r--r-- 1 grahn grahn 32939 Jun 16 21:49 djuras_white.xcf salix:/tmp/xcfbug% md5sum *xcf a1b5381579a94af0822a09d3f37b3e4b djuras_white_bigcanvas.xcf 7812863507ddd7e486bfabdb468f6d78 djuras_white.xcf salix:/tmp/xcfbug% xcfinfo djuras_white.xcf Version 0, 1600x1600 RGB color, 2 layers, compressed RLE - 1670x1653-38-27 RGB-alpha Normal eniro + 1600x1600+0+0 RGB-alpha Normal ekon salix:/tmp/xcfbug% xcfinfo djuras_white_bigcanvas.xcf Version 0, 1670x1653 RGB color, 2 layers, compressed RLE - 1670x1653+0+0 RGB-alpha Normal eniro + 1600x1600+38+27 RGB-alpha Normal ekon salix:/tmp/xcfbug% xcf2pnm -b black -C djuras_white_bigcanvas.xcf ekon |md5sum 141f57dbe4df3f07eb00b58297112e91 - salix:/tmp/xcfbug% xcf2pnm -b black -C djuras_white.xcf ekon |md5sum 141f57dbe4df3f07eb00b58297112e91 - salix:/tmp/xcfbug% xcf2pnm -b black -C djuras_white_bigcanvas.xcf eniro |md5sum 95a6ef319b81ae9f552b6f0ef3c164d9 - salix:/tmp/xcfbug% xcf2pnm -b black -C djuras_white.xcf eniro |md5sum xcf2pnm: Out of memory d41d8cd98f00b204e9800998ecf8427e - zsh: exit 127 xcf2pnm -b black -C djuras_white.xcf eniro | zsh: done md5sum salix:/tmp/xcfbug% valgrind -q xcf2pnm -b black -C djuras_white.xcf eniro |md5sum ==2403== Warning: silly arg (-1794832372) to malloc() xcf2pnm: Out of memory d41d8cd98f00b204e9800998ecf8427e - zsh: exit 127 valgrind -q xcf2pnm -b black -C djuras_white.xcf eniro | zsh: done md5sum salix:/tmp/xcfbug% I'd really appreciate a fix. I could try debugging it myself, but I have a feeling someone else (e.g. the upstream author) who knows XXF better can succeed in an hour or so. regards, Jörgen -- System Information: Debian Release: 5.0.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26.7 (PREEMPT) Locale: LANG=sv_SE, LC_CTYPE=sv_SE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages xcftools depends on: ii libc62.7-18 GNU C Library: Shared libraries ii libpng12-0 1.2.27-2+lenny2 PNG library - runtime Versions of packages xcftools recommends: pn feh | gimageview | gqview | i none (no description available) ii mime-support 3.44-1 MIME files 'mime.types' 'mailcap ii x11-common1:7.3+18 X Window System (X.Org) infrastruc Versions of packages xcftools suggests: ii gimp 2.4.7-1The GNU Image Manipulation Program -- no debconf information djuras_white.xcf.gz Description: GNU Zip compressed data djuras_white_bigcanvas.xcf.gz Description: GNU Zip compressed data
Bug#525179: manpages: ascii(7) extra tables are unreadable if rendered as Postscript
Package: manpages
Version: 3.05-1
Severity: normal
Tags: patch
% man -Tps ascii /tmp/q ; gv /tmp/q
The subsection which starts For convenience, let us give more
compact tables in hex and decimal only renders well to terminals.
Postscript (and I guess HTML, PDF etc) versions have unreadable garbage
here, since it's just ASCII art.
I enclose a patch which simply switches to courier for the tables.
-- System Information:
Debian Release: 5.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.26.7 (PREEMPT)
Locale: LANG=sv_SE, LC_CTYPE=sv_SE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash
manpages depends on no packages.
manpages recommends no packages.
Versions of packages manpages suggests:
ii man-db [man-browser] 2.5.2-4on-line manual pager
-- no debconf information
--- ascii.7 2009/04/22 18:18:24 1.1
+++ ascii.7 2009/04/22 18:29:45
@@ -31,7 +31,7 @@
.\ Modified 1999-08-08 by Michael Haardt (mich...@moria.de)
.\ Modified 2004-04-01 by aeb
.\
-.TH ASCII 7 2008-06-03 Linux Linux Programmer's Manual
+.TH ASCII 7 2009-04-22 Linux Linux Programmer's Manual
.SH NAME
ascii \- the ASCII character set encoded in octal, decimal, and hexadecimal
.SH DESCRIPTION
@@ -123,10 +123,13 @@
\}
.SS Tables
For convenience, let us give more compact tables in hex and decimal.
-.sp
+.PP
.nf
+.if t \{\
+.ft CW
+\}
2 3 4 5 6 7 30 40 50 60 70 80 90 100 110 120
- - -
+-- --
0: 0 @ P \` p 0:( 2F P Z d n x
1: ! 1 A Q a q 1:) 3 = G Q [ e o y
2: 2 B R b r 2:* 4H R \e f p z
Bug#523934: nvi: Searches for national characters in the sv_SE locale show no match
Package: nvi Version: 1.81.6-4 Severity: normal Tags: l10n I dislike UTF-8 for various reasons, and always use iso8859-1 encoding. I just noticed that when I use nvi to edit a file containing non-ASCII characters and search for them (I tried å, ä and ö) nvi reports that there are no matches. For example, if the file contains 'högertå', the search /tå fails. Oddly enough, the search /t[åä] works correctly. This bug is a bit devious: it doesn't cause data corruption, but it's not an obvious bug when it happens -- you are likely to believe that there *is* no match (and act accordingly). nvi 1.79-25 in Debian 4.0 doesn't seem to have this bug. -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26.7 (PREEMPT) Locale: LANG=sv_SE, LC_CTYPE=sv_SE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages nvi depends on: ii libc6 2.7-18 GNU C Library: Shared libraries ii libdb4.2 4.2.52+dfsg-5 Berkeley v4.2 Database Libraries [ ii libncursesw5 5.7+20081213-1 shared libraries for terminal hand Versions of packages nvi recommends: ii nvi-doc 1.81.6-4 4.4BSD re-implementation of vi - d nvi suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522671: fortune-mod: The fortune(6) man page gives the wrong path to data files
Package: fortune-mod Version: 1:1.99.1-3 Severity: minor Quoting fortune(6): ... FILES Note: these are the defaults as defined at compile time. /build/buildd/fortune-mod-1.99.1/debian/tmp/usr/share/games/fortunes Directory for innoffensive fortunes. /build/buildd/fortune-mod-1.99.1/debian/tmp/usr/share/games/fortunes/off Directory for offensive fortunes. ... The paths listed are obviously not the ones where the data files live on my machine. My complaint is minor though, since it doesn't take a genius to realise that the actual path is /usr/share/games/fortunes/ ... By the way, using strace I see that it also searches /usr/local/share/games/fortunes/ in some way. That should be documented, IMHO -- it might be an elegant way to add your own files. -- System Information: Debian Release: 4.0 APT prefers oldstable APT policy: (500, 'oldstable') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-powerpc Locale: LANG=sv_SE, LC_CTYPE=sv_SE (charmap=ISO-8859-1) Versions of packages fortune-mod depends on: ii fortunes [fortune-cook 1:1.99.1-3Data files containing fortune cook ii fortunes-min [fortune- 1:1.99.1-3Data files containing fortune cook ii libc6 2.3.6.ds1-13etch9 GNU C Library: Shared libraries ii librecode0 3.6-12Shared library on which recode is fortune-mod recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507493: /etc/init.d/sysstat prints warnings when sysstat is disabled
Package: sysstat Version: 8.1.2-2 Severity: minor After installing sysstat, my box now displays this while running the init scripts at boot: sadc not enabled in /etc/default/sysstat, not starting. (warning). It looks a bit alarming, because warnings during boot tend to mean something is (slightly) wrong. I believe it should be silent in this case: I have not enabled the daemon, so there is no point warning me about it. Also, the grammar is slightly off -- two end-of-sentence periods. Note that sysstat is useful even with the daemon (or is it a cron job? yes, probably) disabled. It includes mpstat(1) and iostat(1), which both are very useful vmstat-like monitoring tools. Compare with rsync. It's a similar case (comes with a daemon, but is useful without it) but its init script is silent by default. Other than that, thanks for packaging these useful tools. /Jorgen -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26.7 (PREEMPT) Locale: LANG=sv_SE, LC_CTYPE=sv_SE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages sysstat depends on: ii bzip2 1.0.5-1high-quality block-sorting file co ii debconf [debconf-2.0] 1.5.24 Debian configuration management sy ii libc6 2.7-16 GNU C Library: Shared libraries ii lsb-base 3.2-20 Linux Standard Base 3.2 init scrip ii ucf 3.0010 Update Configuration File: preserv Versions of packages sysstat recommends: ii cron 3.0pl1-105 management of regular background p Versions of packages sysstat suggests: pn isag none (no description available) -- debconf information: sysstat/enable: false sysstat/remove_files: true -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#506784: locales: sv_SE locale still fails to collate 'v' and 'w' correctly
Package: locales Version: 2.7-16 Severity: normal Tags: l10n I reported this problem in #502356 six weeks ago, on glibc/2.3.6.ds1-13etch7. The bug was closed as (already) fixed in 2.7-1, then it was archived. And then I upgraded to testing and saw that the bug is still there, so I guess I have to file a new one. To reproduce, simply do this: salix:~% /bin/echo -e vword\nwword | env LC_COLLATE=sv_SE.iso88591 sort wword vword salix:~% In sv_SE, 'w' is a variant of 'v', and collates after 'v' if and only if the words are otherwise identical. This works much (most?) of the time, but obviously not for the words above. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26.7 (PREEMPT) Locale: LANG=sv_SE, LC_CTYPE=sv_SE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages locales depends on: ii debconf [debconf-2.0] 1.5.24 Debian configuration management sy ii libc6 [glibc-2.7-1] 2.7-16 GNU C Library: Shared libraries locales recommends no packages. locales suggests no packages. -- debconf information: locales/default_environment_locale: en_US.ISO-8859-15 locales/locales_to_be_generated: en_US ISO-8859-1, en_US.ISO-8859-15 ISO-8859-15, en_US.UTF-8 UTF-8, sv_SE ISO-8859-1, sv_SE.ISO-8859-15 ISO-8859-15, sv_SE.UTF-8 UTF-8 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#504629: gnuplot-x11: docs say x11 is the default terminal, but it's wxt
Package: gnuplot-x11 Version: 4.2.2-1.2 Severity: minor The man page says ... provides the x11 terminal type for use with X servers. This terminal type is set automatically at startup if the DISPLAY environment variable ... and so on. help set terminal x11 says the same thing. But in fact the xwt terminal has priority; see term.c/init_terminal(). It might also be a good idea to write a few words about $GNUTERM in the man page, for those of us who like the x11 terminal, find the wxt terminal loathsome, and don't have the patience to look it up in the texinfo documentation. The x11 terminal is what many people are used to -- it's default up to and including Debian Etch. From what I have seen of the wxt driver, I doubt that it can handle my large data sets, or work well over a non-local X11 session. I guess I'm saying that I don't want it as default ;-) -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26.7 (PREEMPT) Locale: LANG=sv_SE, LC_CTYPE=sv_SE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages gnuplot-x11 depends on: ii gnuplot-nox4.2.2-1.2 A command-line driven interactive ii libc6 2.7-15GNU C Library: Shared libraries ii libcairo2 1.6.4-6.1 The Cairo 2D vector graphics libra ii libfreetype6 2.3.7-2 FreeType 2 font engine, shared lib ii libgcc11:4.3.2-1 GCC support library ii libgd2-xpm 2.0.36~rc1~dfsg-3 GD Graphics Library version 2 ii libglib2.0-0 2.16.6-1 The GLib library of C routines ii libjpeg62 6b-14 The Independent JPEG Group's JPEG ii libpango1.0-0 1.20.5-3 Layout and rendering of internatio ii libpng12-0 1.2.27-2 PNG library - runtime ii libstdc++6 4.3.2-1 The GNU Standard C++ Library v3 ii libwxbase2.6-0 2.6.3.2.2-3 wxBase library (runtime) - non-GUI ii libwxgtk2.6-0 2.6.3.2.2-3 wxWidgets Cross-platform C++ GUI t ii libx11-6 2:1.1.5-2 X11 client-side library ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime gnuplot-x11 recommends no packages. gnuplot-x11 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#504281: djview4: File/Open dialogue refuses to list any files except *.{djvu,djv}
Package: djview4
Version: 4.3-4
Severity: important
With the djview in Etch, I was annoyed that the File/Open dialogue defaulted
to *.{djvu,djv}, and had no memory for me choosing another one. I even patched
it away at one point. With 4.3-4, there *is* no way to specify other file names
except typing the full file name manually. (Unless there is some Gnome or KDE
or whatever-desktop-environment-is-tied-to-Qt global preference for file
dialogues -- I use a traditional (c)twm desktop and don't have those utilities.)
Since Debian isn't MS-DOS and file name extensions carry no specific meaning,
I suggest that the default should be not to discriminate against file names
at all (except dotfiles, I guess).
(Sorry for the sarcasm. None of my DjVu files have file extensions, so this
feature is a problem for me. I will hack my local djview4 copy later.)
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.26-1-amd64 (SMP w/1 CPU core)
Locale: LANG=sv_SE, LC_CTYPE=sv_SE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash
Versions of packages djview4 depends on:
ii libc62.7-15 GNU C Library: Shared libraries
ii libdjvulibre21 3.5.20-8+lenny0 Runtime support for the DjVu image
ii libgcc1 1:4.3.2-1 GCC support library
ii libjpeg626b-14 The Independent JPEG Group's JPEG
ii libqt4-network 4.4.3-1 Qt 4 network module
ii libqtcore4 4.4.3-1 Qt 4 core module
ii libqtgui44.4.3-1 Qt 4 GUI module
ii libstdc++6 4.3.2-1 The GNU Standard C++ Library v3
ii libtiff4 3.8.2-11Tag Image File Format (TIFF) libra
ii libx11-6 2:1.1.5-2 X11 client-side library
ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar
ii xdg-utils1.0.2-6 desktop integration utilities from
Versions of packages djview4 recommends:
ii djvulibre-plugin 3.5.20-8+lenny0 Browser plugin for the DjVu image
Versions of packages djview4 suggests:
ii djvulibre-bin3.5.20-8+lenny0 Utilities for the DjVu image forma
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#504340: djvulibre-plugin: Iceweasel crashes when loading DjVu documents
Package: djvulibre-plugin Version: 3.5.20-8+lenny0 Severity: important I just upgraded to Lenny today, and Iceweasel+djvulibre-plugin stopped working. Opera didn't like it either (opera: Plug-in 11604 is not responding. It will be closed.) so I suspect the plugin. Tried changing /etc/alternatives from djview4 to djview3 -- didn't work better. What happens is I try to access any DjVu document using IceWeasel, for example the Washington letter linked from http://ncrec.dcr.state.nc.us/Cat/CatServer.asp?WCI=MainEpWCE=CatV1WCU=510.1 and I see a new widget or something flash by briefly. Then iceweasel leaves this in ~/.xsession-errors (firefox-bin:11628): Pango-WARNING **: Error loading GPOS table 5503 djview: QDjViewPlugin::exec() begin djview: QDjViewPlugin::exec() end code=0 and segfaults: salix:~% gdb /usr/lib/iceweasel/firefox-bin core.11739 GNU gdb 6.8-debian ... Core was generated by `/usr/lib/iceweasel/firefox-bin -a iceweasel http://www.djvu.org/gallery/'. Program terminated with signal 11, Segmentation fault. [New process 11739] [New process 11751] [New process 11750] [New process 11748] [New process 11747] [New process 11746] [New process 11743] [New process 11742] #0 0x7f5f33ad3ed5 in raise () from /lib/libc.so.6 (gdb) bt #0 0x7f5f33ad3ed5 in raise () from /lib/libc.so.6 #1 0x7f5f32778715 in ?? () from /usr/lib/iceweasel/xulrunner/libxul.so #2 signal handler called #3 0x7f5f27820730 in NPP_SetWindow () from /usr/lib/netscape/plugins-libc6/nsdejavu.so #4 0x7f5f32d3e9f9 in ?? () from /usr/lib/iceweasel/xulrunner/libxul.so #5 0x7f5f32d53aee in ?? () from /usr/lib/iceweasel/xulrunner/libxul.so #6 0x7f5f32d4d55a in ?? () from /usr/lib/iceweasel/xulrunner/libxul.so #7 0x7f5f3291364b in ?? () from /usr/lib/iceweasel/xulrunner/libxul.so #8 0x7f5f329175d6 in ?? () from /usr/lib/iceweasel/xulrunner/libxul.so #9 0x7f5f32a11755 in ?? () from /usr/lib/iceweasel/xulrunner/libxul.so #10 0x7f5f32a14034 in ?? () from /usr/lib/iceweasel/xulrunner/libxul.so #11 0x7f5f32ea6562 in ?? () from /usr/lib/iceweasel/xulrunner/libxul.so #12 0x7f5f32e7c652 in ?? () from /usr/lib/iceweasel/xulrunner/libxul.so #13 0x7f5f32e01065 in ?? () from /usr/lib/iceweasel/xulrunner/libxul.so #14 0x7f5f32ce4601 in ?? () from /usr/lib/iceweasel/xulrunner/libxul.so #15 0x7f5f32772208 in XRE_main () from /usr/lib/iceweasel/xulrunner/libxul.so #16 0x004014cb in ?? () #17 0x7f5f33ac01a6 in __libc_start_main () from /lib/libc.so.6 #18 0x00401139 in ?? () #19 0x7fff3c51ee68 in ?? () #20 0x001c in ?? () #21 0x0004 in ?? () #22 0x7fff3c520bde in ?? () #23 0x7fff3c520c0a in ?? () #24 0x in ?? () (gdb) I think I should mention that the djview4 in the list below was hacked by me to avoid the djview4 bug I reported earlier today ... but (a) it's a two-line patch and (b) I get the same results whatever I choose in /etc/alternatives (above was djview3 I think). regards, Jorgen -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/1 CPU core) Locale: LANG=sv_SE, LC_CTYPE=sv_SE (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Shell: /bin/sh linked to /bin/bash Versions of packages djvulibre-plugin depends on: ii djview3 3.5.20-8+lenny0 Viewer for the DjVu image format ii djview4 4.3-4+0.grahn.1 Viewer for the DjVu image format ii libc62.7-15 GNU C Library: Shared libraries Versions of packages djvulibre-plugin recommends: ii iceweasel 3.0.3-2lightweight web browser based on M Versions of packages djvulibre-plugin suggests: ii mime-support 3.44-1 MIME files 'mime.types' 'mailcap -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502356: locales: sv_SE locale sometimes fail to collate 'v' and 'w' correctly
Package: locales Version: 2.3.6.ds1-13etch7 Severity: normal Tags: l10n I was doing a bit of C++ programming, and replacing my own swedish collation algorithm with the standard locales (through the standard C++ std::locale interface), when my unit tests started to fail. It turned out I could repeat it with the standard sort utility, so that's what I'll use here. This quote from /usr/share/i18n/locales/sv_SE describes what the locale intends to implement, and it's also the rule I am familiar with from real life: % The letter w is normally not present in the Swedish alphabet. It % exists in some names in Swedish and foreign words, but is accounted % for as a variant of 'v'. Words and names with 'w' are in Swedish % ordered alphabetically among the words and names with 'v'. If two % words or names are only to be distinguished by 'v' or % 'w', 'v' is % placed before 'w'. And that seems to work *some* of the time ... out of the following three examples, the two first are ok and show how it should work. The third is simply wrong -- wword and vword are identical except one contains the 'w' variant of the letter 'v', and should thus collate last. tuva:~ /bin/echo -e word\nvorm | env LC_COLLATE=sv_SE.iso88591 sort word vorm tuva:~ /bin/echo -e word\nvord | env LC_COLLATE=sv_SE.iso88591 sort vord word tuva:~ /bin/echo -e vword\nwword | env LC_COLLATE=sv_SE.iso88591 sort wword vword tuva:~ I have not done any further experiments to see what triggers it. I cannot help suspecting that similar rules for other languages are affected as well ... Final side note: Solaris 8 passes this test. That's the only other Unix I've tested. regards, Jorgen -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-powerpc Locale: LANG=sv_SE.utf8, LC_CTYPE=sv_SE.utf8 (charmap=UTF-8) Versions of packages locales depends on: ii debconf [debconf-2.0] 1.5.11etch2 Debian configuration management sy ii libc6 [glibc-2.3.6.ds1 2.3.6.ds1-13etch7 GNU C Library: Shared libraries locales recommends no packages. -- debconf information: locales/default_environment_locale: en_US locales/locales_to_be_generated: en_US ISO-8859-1, sv_SE.UTF-8 UTF-8, sv_SE ISO-8859-1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502360: Race conditions with 'screen -X cmd' and 'screen cmd' cause logging to file to fail
Package: screen
Version: 4.0.3-0.3
Severity: normal
At work, we automate things with screen, invoked from shell scripts. Among
other things, the scripts create new, named windows and turn on logging for
them. This broke when we upgraded from 4.0.2 to screen 4.0.3.
(Actually, we run RedHat Enterprise Linux, but the problem is repeatable with
Debian. Either upstream 4.0.3 did this, or RH and Debian include the same
bad patch.)
The symptom is that if you create windows too fast (by calling the screen
binary)
and send commands too fast (by calling screen -X cmd) some of them will fail.
It's easy to see if you start a screen and run this shell script:
--
#!/bin/sh
[ -z $STY ] {
echo no screen
exit 1
}
mkdir -p /tmp/qgrajor || exit 1
for name in $(seq 1 5) ; do
name=screen_$name
screen -t $name sort
# sleep 1 # enabling this delay fixes the problem
screen -p $name -X logfile /tmp/bug-$name
screen -p $name -X log on
done
--
What typically happens is that screen_5 doesn't get logging enabled,
but other problems may happen too (other windows not having logging,
maybe also windows not opening).
I feel this is a serious regression because it prevents automation. I can add
a delay like the one commented out above, but I have no idea if one second
is always sufficient. It's not a good workaround.
regards,
Jorgen
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: powerpc (ppc)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-3-powerpc
Locale: LANG=sv_SE.utf8, LC_CTYPE=sv_SE.utf8 (charmap=UTF-8)
Versions of packages screen depends on:
ii base-passwd3.5.11Debian base system master password
ii debconf [debconf-2.0] 1.5.11etch2 Debian configuration management sy
ii libc6 2.3.6.ds1-13etch7 GNU C Library: Shared libraries
ii libncursesw5 5.5-5 Shared libraries for terminal hand
ii libpam0g 0.79-5Pluggable Authentication Modules l
ii passwd 1:4.0.18.1-7 change and administer password and
screen recommends no packages.
-- debconf information:
screen/old_upgrade_prompt: false
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466072: cannot create new windows in a detached screen session
Package: screen Version: 4.0.3-0.3 Severity: normal This is likely to bite people who do semi-advanced scripting involving screen. Consider this example script: #!/bin/sh [ $STY ] || exit 1 sleep 5 screen -t one sh -c sleep 5; ping -c20 localhost | tee /tmp/1 echo $? sleep 1 screen -t two sh -c sleep 10; ping -c20 localhost | tee /tmp/2 echo $? If I run it inside an attached screen, it does the obvious: creates two temporary windows after 5s, and run ping inside them. But if I detach before the 5s have passed, neither window is created and ping is not run. Both screen invocations still exit successfully. I have no idea if there is a good reason for this behavior. If there is, I can't see it. The screen FAQ doesn't mention what should happen, but everything else works so insanely well with detached screens, so this comes as a complete surprise. It's not Debian-specific because I see it on RedHat Enterprise Linux 4 too ... but it is easier to report it in a well-known and open place like Debian's BTS than to RH or the screen mail address. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-powerpc Locale: LANG=sv_SE, LC_CTYPE=sv_SE (charmap=ISO-8859-1) Versions of packages screen depends on: ii base-passwd3.5.11Debian base system master password ii debconf [debconf-2.0] 1.5.11etch1 Debian configuration management sy ii libc6 2.3.6.ds1-13etch4 GNU C Library: Shared libraries ii libncursesw5 5.5-5 Shared libraries for terminal hand ii libpam0g 0.79-5Pluggable Authentication Modules l ii passwd 1:4.0.18.1-7 change and administer password and screen recommends no packages. -- debconf information: screen/old_upgrade_prompt: false -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#437446: libjpeg-progs: jpegexiforient(1) man page is illegible when formatted as Postscript
Package: libjpeg-progs Version: 6b-13 Severity: normal The command man -Tps jpegexiforient jpegexiforient.1.ps renders a fairly unreadable version of the man page, because it contains tables and ASCII graphics which assumes a fixed-width font. I would have provided a patch, but the first line of the man page source says: .\ DO NOT MODIFY THIS FILE! It was generated by help2man 1.35. This is not the time and place for a rant, but sub-standard tools for creating sub-standard man pages irritate me -- troff isn't *that* hard! -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-powerpc Locale: LANG=sv_SE, LC_CTYPE=sv_SE (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#437453: libjpeg-progs: improve readability of jpegtran(1) man page
Package: libjpeg-progs Version: 6b-13 Severity: normal Tags: patch The long option list in the jpegtran(1) man page is heavily divided into paragraphs -- some belonging with a certain option, some serving as into to a whole subsection of the options. Indenting the paragraphs to match the option they belong to improves readability a lot, in my humble opinion. I include a patch which does that. The patch also makes the man page mention which option preserves Exif comments -- I keep forgetting and have to experiment to remember. --- jpegtran.1.orig 2007-08-12 18:26:06.0 +0200 +++ jpegtran.1 2007-08-12 18:23:58.0 +0200 @@ -91,12 +91,12 @@ .TP .B \-transverse Transverse transpose (across UR-to-LL axis). -.PP +.IP The transpose transformation has no restrictions regarding image dimensions. The other transformations operate rather oddly if the image dimensions are not a multiple of the iMCU size (usually 8 or 16 pixels), because they can only transform complete blocks of DCT coefficient data in the desired way. -.PP +.IP .BR jpegtran 's default behavior when transforming an odd-size image is designed to preserve exact reversibility and mathematical consistency of the @@ -108,7 +108,7 @@ of transpose and flip operations; for consistency, their actions on edge pixels are defined to be the same as the end result of the corresponding transpose-and-flip sequence. -.PP +.IP For practical use, you may prefer to discard any untransformable edge pixels rather than having a strange-looking strip along the right and/or bottom edges of a transformed image. To do this, add the @@ -117,7 +117,7 @@ .TP .B \-trim Drop non-transformable edge blocks. -.PP +.IP Obviously, a transformation with .B \-trim is not reversible, so strictly speaking @@ -130,7 +130,7 @@ followed by .B \-rot 180 -trim trims both edges. -.PP +.IP If you are only interested by perfect transformation, add the .B \-perfect switch: @@ -138,8 +138,9 @@ .B \-perfect Fails with an error if the transformation is not perfect. For example you may want to do -.TP +.IP .B (jpegtran \-rot 90 -perfect foo.jpg || djpeg foo.jpg| pnmflip \-r90 | cjpeg) +.IP to do a perfect rotation if available or an approximated one if not. .PP @@ -151,25 +152,24 @@ corner up and/or left to make it so, simultaneously increasing the region dimensions to keep the lower right crop corner unchanged. (Thus, the output image covers at least the requested region, but may cover more.) - +.IP Note: .B \-perfect and .B lossless-crop are enhancements from http://sylvana.net/jpegcrop/ that may not be available on non-Debian systems. - +.PP The image can be losslessly cropped by giving the switch: .TP .B \-crop WxH+X+Y Crop to a rectangular subarea of width W, height H starting at point X,Y. .PP -.PP Another not-strictly-lossless transformation switch is: .TP .B \-grayscale Force grayscale output. -.PP +.IP This option discards the chrominance channels if the input image is YCbCr (ie, a standard color JPEG), resulting in a grayscale JPEG file. The luminance channel is preserved exactly, so this is a better method of reducing @@ -193,9 +193,11 @@ .TP .B \-copy all Copy all extra markers. This setting preserves miscellaneous markers -found in the source file, such as JFIF thumbnails and Photoshop settings. +found in the source file, such as +Exif data, +JFIF thumbnails and Photoshop settings. In some files these extra markers can be sizable. -.PP +.IP The default behavior is .BR \-copy comments . (Note: in IJG releases v6 and v6a, -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-powerpc Locale: LANG=sv_SE, LC_CTYPE=sv_SE (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
