Bug#338661: pnmnorm: segfault due to compiler optimization bug

[Alan Curry]

Package: netpbm
Version: 2:10.0-8sarge1
Severity: normal

pnmnorm segfaults under certain circumstances, because of a mis-compilation
by gcc -O3 on ppc. Recompiling the package with -O2 results in a working
pnmnorm.

Reproducing the segfault is difficult because whether it occurs depends on
a very obscure detail of its invocation. The buggy compiler inlines some
stuff into main(), and generates code which uses the register r18 without
initializing it. The value of r18 isn't predictable at that point because
(here comes the fun part) nothing in the entire process has touched it, and
it still holds whatever value was in it before the execve!

The contents of r18 immediately before execve depend on what program is doing
the exec. I have found that ash and bash are both more likely to lead to a
segfault than zsh and tcsh. And if you try to chase this bug down with
strace, its interception of execve() changes the registers enough to prevent
(or perhaps, depending on how your strace was compiled, cause) the segfault.
Best. Heisenbug. Ever.!

It may also be kernel dependent (I doubt you can expect every kernel to 
leave r18 untouched all the way through execve.)

This script causes the segfault reliably for me.

#!/bin/ash
pnmnorm 

Bug#312722: telnet 0 25 no longer works

[Alan Curry]

Package: telnet
Version: 0.17-29
Severity: minor

This has been discussed before:


And redhat seems to have already experienced it and fixed it too:


Quoting from the redhat bug report:

  For the past - Oh, I don't know, two decades? - 0 resolves to
  127.0.0.1, and so "telnet 0 25" would connect to the local machine's
  smtp server, or "telnet 0 80" connects to the local HTTP server.  Not
  so in RHEL3.  WTF?

WTF indeed. "telnet 0 25" (12 keystrokes including the RET) is now "telnet
localhost 25" (19 keystrokes), a >36% increase in manual labor, which will
surely cause a carpal tunnel epidemic if not repealed.

"telnet 0.0.0.0 25" still works, but it's sooo awkward.

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.4.29
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages telnet depends on:
ii  libc6   2.3.2.ds1-22 GNU C Library: Shared libraries an
ii  libgcc1 1:3.4.3-13   GCC support library
ii  libncurses5 5.4-4Shared libraries for terminal hand
ii  libstdc++5  1:3.3.5-13   The GNU Standard C++ Library v3
ii  netbase 4.21 Basic TCP/IP networking system

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#312728: wu-ftpd: please reinstate SITE CHMOD

[Alan Curry]

Package: wu-ftpd
Version: 2.6.2-20
Severity: normal

When -DPARANOID was added to the configuration, SITE CHMOD and SITE UMASK
were killed. The only way this can be justified is if there is supposed to be
a single "correct" umask that results in the correct permissions on all files
uploaded by all users; or alternately that the users don't mind bouncing back
and forth between an FTP client for uploading and a login shell for chmod'ing.

Those are tough conditions to meet. Can we have SITE CHMOD back, please?

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.4.29
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages wu-ftpd depends on:
ii  debconf 1.4.30.13Debian configuration management sy
ii  libc6   2.3.2.ds1-22 GNU C Library: Shared libraries an
ii  libpam0g0.76-22  Pluggable Authentication Modules l
ii  netbase 4.21 Basic TCP/IP networking system
ii  perl [perl5]5.8.4-8  Larry Wall's Practical Extraction 

-- debconf information:
* wu-ftpd/create-incoming: false
  wu-ftpd/homedir: /home/ftp
  wu-ftpd/update-binaries:
  wu-ftpd/home-noexist: true
  wu-ftpd/libnss:
* wu-ftpd/anonymous: true
  wu-ftpd/homedir-not-absolute:
  wu-ftpd/ftpusers: false
* wu-ftpd/run_mode: inetd
  wu-ftpd/homedir-exists: false
  wu-ftpd/ftpusers-symlink:


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#312935: groff-base: grotty -c should be - no it MUST be - made the default

[Alan Curry]

Package: groff-base
Version: 1.18.1.1-7
Severity: normal

Let's begin with some quotes from grotty(1):

  By default, grotty emits SGR escape sequences (from ISO 6429, also
  called ANSI color escapes)

  ...

  For SGR support, it is necessary to use the -R option of less(1)
  to disable the interpretation of grotty's old output format.
  Consequently, all programs which use less as the pager program have
  to pass this option to it.

Instructions of the form "all programs ... have to ..." should be taken as a
warning that whatever's being documented is a disruptive misfeature, and this
is a perfect example.

In previous versions of groff (for example the last version of groff in
woody, and as far as I know every version of groff in every version of Debian
prior to sarge), this worked:

  ( echo .ft B ; echo bold ; echo .ft R ; echo not bold ) > foo
  nroff foo | less

Now it doesn't. Instead it shows ESC[1m and ESC[22m. grotty(1) documents a
splendid variety of ways to avoid this outcome: by setting an environment
variable, adding an option to the grotty command line, or sticking a
directive into the intermediate [di]troff output. There are so many ways to
disable this new behavior, you can't avoid thinking that the perpetrator must
have known he was about to cause a lot of trouble.

The burden of tracking down scripts that need to be rewritten, changing options,
and setting environment variables rightly belongs on the few who want the new
functionality, not the many who were happy with nroff as it has always been.
Enabling a new, incompatible output format by default and then boldly
declaring that "all programs ... have to" adapt to it is arrogant and rude.

The advice to use less -R is helpful to some people, I suppose, but it is
basically a layering violation. Decades of UNIX tradition have established
the basic rules to be followed when the PAGER environment variable is used.
It can be assumed that the PAGER behaves reasonably on sequences like
b^Hbo^Hol^Hld^Hd, showing it as the world "bold" in bold if possible, but it
cannot be assumed that the PAGER is less, or that the PAGER has a less-ish -R
option or that it can interpret sequences like ESC[1m. PAGER is a protocol.
One side does not get to unilaterally dictate changes in the other.

grotty is violating the Robustness Principle here: be conservative in what
you send.

Aside from that, the use of ANSI escape sequences without regard to the TERM
environment variable is an unwarranted assumption. less interprets
b^Hbo^Hol^Hld^Hd by outputting the correct escape sequences for the terminal
in use. less -R just passes through the ESC[1m, which does no good on a Wyse
terminal. All the world's not a VT100.

Apparently, some of these problems have already been noticed, because
/etc/groff/man.local contains the magic code to enable the sensible,
backward-compatible behavior. But if it was correct to make that decision for
man pages, why shouldn't it be done for all other uses of nroff too?

Please, if upstream will not reverse the default, do it in the Debian
package, for all of the reasons listed above. This ill-conceived new behavior
must not stand.

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.4.29
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages groff-base depends on:
ii  libc6   2.3.2.ds1-22 GNU C Library: Shared libraries an
ii  libgcc1 1:3.4.3-13   GCC support library
ii  libstdc++5  1:3.3.5-13   The GNU Standard C++ Library v3

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#298185: pppoe: braindamage in the configure script

[Alan Curry]

Package: pppoe
Version: 3.5-4
Followup-For: Bug #298185

The reason pppoe-server -k isn't working is that the configure script
conflates 2 configuration items that should be separate:

1. Do you want to build the pppd plugin (no, we don't because it's already
included in the ppp-2.4.3 package)
2. Do you want to _use_ the pppd plugin (yes, we do because kernel mode pppoe
is a Good Thing)

The configure script doesn't recognize this as valid. If you want to be able
to use the plugin from pppoe-server, you have to build it here too.

The relevant part of configure.in is:

if test "$ac_cv_header_linux_if_pppox_h" = yes ; then
if test "$ac_cv_pluginpath" != no ; then
LINUX_KERNELMODE_PLUGIN=rp-pppoe.so
AC_DEFINE(HAVE_LINUX_KERNEL_PPPOE)
PPPD_INCDIR=$ac_cv_pluginpath
fi
fi

The AC_DEFINE(HAVE_LINUX_KERNEL_PPPOE) is what enables pppoe-server -k (and
it has no other effect). In my opinion, HAVE_LINUX_KERNEL_PPPOE should simply
be defined unconditionally, either by configure.in or by a #define in
pppoe-server.c after #include "config.h".

If -k is attempted on a system whose kernel or pppd doesn't support it,
connections will fail and you'll have to read your log to see that pppd
failed to load or initialize the plugin. This may be an argument against
making -k a default, but it's surely not a reason to keep kernel-mode support
out of Debian's pppoe-server forever.

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.4.29
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages pppoe depends on:
ii  libc6   2.3.2.ds1-22 GNU C Library: Shared libraries an
ii  ppp 2.4.3-20050321+2 Point-to-Point Protocol (PPP) daem

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#298582: workaround: enable kernel mode

[Alan Curry]

Package: pppoe
Version: 3.5-4
Followup-For: Bug #298582

I've had the same problem, which went away immediately after enabling kernel
mode (pppoe-server -k). To do that you first need to get #298185 fixed
though. I've just sent a proposed solution to that bug.

I have no explanation on why the non-kernelmode pppoe-server responses are
getting lost, but I saw the same pattern: pppd thinks that it's sending
replies, but the interface on which they should be going out is not sending
anything. I may do some further research on that later but first I've got one
more pppoe bugreport to compose. It'll be coming in a few minutes.

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.4.29
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages pppoe depends on:
ii  libc6   2.3.2.ds1-22 GNU C Library: Shared libraries an
ii  ppp 2.4.3-20050321+2 Point-to-Point Protocol (PPP) daem

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#313476: pppoe-server passes borked options to pppoe

[Alan Curry]

Package: pppoe
Version: 3.5-4
Severity: important

pppoe-server uses snprintf() to build a pppoe command line. Somewhere between
pppoe-3.3 and pppoe-3.5, an extra parameter was added, but the order is mixed
up. Here's the relevant section of a diff between 3.3 and 3.5:

-snprintf(buffer, SMALLBUF, "%s -n -I %s -e 
%d:%02x:%02x:%02x:%02x:%02x:%02x%s",
+/* Let's hope service-name does not have ' in it... */
+snprintf(buffer, SMALLBUF, "%s -n -I %s -e 
%d:%02x:%02x:%02x:%02x:%02x:%02x%s -S '%s'",
 PPPOE_PATH, session->ethif->name,
 ntohs(session->sess),
 session->eth[0], session->eth[1], session->eth[2],
 session->eth[3], session->eth[4], session->eth[5],
+session->serviceName,
 PppoeOptions);

As you can see above, the "-S '%s'" was added to the end of the format
string, but the serviceName, which should corresponds to it, got added in the
next-to-last argument position. So the PppoeOptions (which includes things
like -m mtu and -T timeout) are being used as a service name, and the service
name is getting crammed onto the end of the peer's MAC address. (PppoeOptions
begins with a space so it would not be crammed up against the MAC address if
it were in that position. serviceName is most often an empty string, which
explains why its bad positioning hasn't been noticed.)

The solution is to reverse the last 2 args in that snprintf.

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.4.29
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages pppoe depends on:
ii  libc6   2.3.2.ds1-22 GNU C Library: Shared libraries an
ii  ppp 2.4.3-20050321+2 Point-to-Point Protocol (PPP) daem

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#310672: ppp: brX is broken too and the workaround is no good

[Alan Curry]

Package: ppp
Version: 2.4.3-20050321+2
Followup-For: Bug #310672

Also look at the test for "br" interfaces. It doesn't allow less than 4
characters in the interface name, so you can't use br0-br9 but you can use
br10. That's just dumb.

As for using the nic- prefix, that doesn't work with pppoe-server because
pppoe-server doesn't recognize the nic- prefix on the -I option, which is
where it gets the name it passes down to pppd as well as where it gets the
name to bind to for reading requests.

Maybe pppoe-server *should* recognize the nic- prefix on the -I option, or
maybe it should add the nic- prefix when it invokes pppd. (In fact, now that I
think about it, I'm pretty sure it should do the latter.)

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.4.29
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages ppp depends on:
ii  libc6   2.3.2.ds1-22 GNU C Library: Shared libraries an
ii  libpam-modules  0.76-22  Pluggable Authentication Modules f
ii  libpam-runtime  0.76-22  Runtime support for the PAM librar
ii  libpam0g0.76-22  Pluggable Authentication Modules l
ii  libpcap0.7  0.7.2-7  System interface for user-level pa
ii  makedev 2.3.1-77 creates device files in /dev
ii  netbase 4.21 Basic TCP/IP networking system
ii  procps  1:3.2.1-2The /proc file system utilities
ii  zlib1g  1:1.2.2-4compression library - runtime

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#298582: pppoe: looks like a pppd bug

[Alan Curry]

Package: pppoe
Version: 3.5-4
Followup-For: Bug #298582

I have found a bug in pppd that may explain why this happens.

pppoe-server invokes "pppd pty 'pppoe ...'" with no file descriptors open.
pppd does an openlog() and gets /dev/log on fd 0 (you can already see where
this is going).

Later, when pppd is setting up file descriptors for the pty subprocess, it
puts the pty master on fd 0 and 1 and the logfd (which is a distinct log
file, in addition to syslog, normally set to /dev/null by now) on fd 2. It
handles this all very carefully, avoiding several potential problems with fds
getting stomped on. Then it does a closelog(), which stomps on fd 0.

pppoe now gets invoked with fd 0 closed, and hilarity ensues.

Moving the closelog() up a few lines in pppd fixes it for me.

--- ppp-2.4.3.orig/pppd/main.c  2004-11-13 07:05:48.0 -0500
+++ ppp-2.4.3/pppd/main.c   2005-06-19 05:13:27.0 -0500
@@ -1497,6 +1497,8 @@
if (errfd == 0 || errfd == 1)
errfd = dup(errfd);
 
+   closelog();
+
/* dup the in, out, err fds to 0, 1, 2 */
if (infd != 0)
dup2(infd, 0);
@@ -1505,7 +1507,6 @@
if (errfd != 2)
dup2(errfd, 2);
 
-   closelog();
if (log_to_fd > 2)
close(log_to_fd);
if (the_channel->close)


-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.4.29
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages pppoe depends on:
ii  libc6   2.3.2.ds1-22 GNU C Library: Shared libraries an
ii  ppp 2.4.3-20050321+2 Point-to-Point Protocol (PPP) daem

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#318081: PATCH: DWARF2 macinfo-related fixes for gdb and gcc

[Alan Curry]

[skip to the end if you just want the patches without the storyline]

Jochen Voss writes the following:
>
>when trying to debug one of my programs I encountered a case where gdb
>crashed on the command "break main" before my programm was even
>started.  The problem occurs on a powerpc machine.

After investigating, I don't see anything ppc-specific about this bug.
The actual occurrence of the segfault may vary between architectures, but
that's just because some may get lucky when dereferencing the bad pointer.

>http://seehuhn.de/data/gdb-bug   - the binary
>http://seehuhn.de/data/gdb-bug.i - the preprocessed source
[...]
>(gdb) break main
>Segmentation fault

It also has nothing to do with setting a breakpoint, or with your main
function. You can also try "print main", "break load_matrix", ... the key is
convincing gdb that it needs to parse the debugging symbols.

>2) Regenerating the binary.  The binary gdb-bug was compiled from
>gdb-bug.i using the following two commands:
>
>[EMAIL PROTECTED] [~/y] gcc -ggdb3 -c gdb-bug.i
>[EMAIL PROTECTED] [~/y] gcc -ggdb3 -o gdb-bug gdb-bug.o -lm -llapack 
> -lblas -lg2c

When done with gcc 3.3 or 3.4, the resulting executable does not segfault
gdb. I can see from your binary that you were using Debian's gcc 4.0.1-1. I
can also reproduce the bug with the current upstream source, 4.0.2. (gcc 4.0
hasn't made it into Debian stable yet).

Also, your use of -ggdb3 is an important part of reproducing the bug. Normal
-g doesn't include debugging information for macros, and that's where the
problem is. (-gdwarf-2 -g3 is also sufficient, or just -g3 since DWARF2 seems
to be the default format now)

To see what is going wrong, do a "readelf -w gdb-bug.o" and look at the
.debug_macinfo section. You'll see that it references sources files by
number, starting at 1 and ending at 47:

  ...
  DW_MACINFO_start_file - lineno: 21 filenum: 46
  DW_MACINFO_end_file
  DW_MACINFO_start_file - lineno: 22 filenum: 47

Those filenums refer to "The File Name Table" (located earlier in the
readelf -w output). If you take a look at The File Name Table, you'll see
that it has only 46 entries. And that's why gdb segfaults. Now we know how to
fix gdb: make it check that filenum is in the proper range.

But we want to fix the bad debugging information, not just the segfault. Go
back to the .debug_macinfo section, look closer, and you'll see that there
are no references to filenum 16. It goes 1,2,3,...15,17,18,...47 (some
numbers are repeated because files get #included more than once, but if you
look just at the first appearance of each number, they are in order.)

When gcc was building this table of #included files, it was also keeping
track of #includes for error reporting purposes. There are 2 lists of
#included files: one for errors and warnings, and the other for DWARF2
debugging information. The missing file number 16 corresponds to the special
pseudo-file "" in the list of source files. "" is omitted
from the DWARF2 file table because it's not an actual file.

There is a function called maybe_emit_file() in gcc, which assigns the
filenums, and takes care of mapping the file numbers in the main file list
to the file numbers in the DWARF2 list. Someone forgot to use the return
value of maybe_emit_file() when creating the DW_MACINFO_start_file record, so
what should be a reference to file number 16 comes out instead as a reference
to file number 17. After the 16th entry, every filenum is 1 larger than it
should be. The reference to file number 47 should really be a reference to
file number 46.

Because all file numbers after the missing one are off by 1, most of the
macro debugging information is going to be referring to the wrong file. So
even if gdb doesn't segfault, it's still going to report the wrong origin for
macros defined after the bug's trigger point (file 16 in the sample).

It would be possible to make gdb detect an out-of-sequence filenum and
automatically adjust it and all of the following filenums, with a warning
message like "Detected GCC 4.0.<=2 macinfo breakage, working around it". My
patch doesn't go that far; it just prevents the segfault.

Here are the patches. In case of mail corruption, they're also here:
http://world.std.com/~pacman/gcc4-dwarf-macinfo.diff
http://world.std.com/~pacman/gdb-macinfo-segfault.diff

--- gdb-6.3.orig/gdb/dwarf2read.c   2005-10-17 23:22:46.0 -0500
+++ gdb-6.3/gdb/dwarf2read.c2005-10-18 00:38:48.0 -0500
@@ -9087,9 +9087,14 @@
 file = read_unsigned_leb128 (abfd, mac_ptr, &bytes_read);
 mac_ptr += bytes_read;
 
-current_file = macro_start_file (file, line,
- current_file, comp_dir,
- lh, cu->objfile);
+if (file > lh->num_file_names)
+  warning ("macro debug info references file %d, "
+   "but file table only contains %u

Bug#273008: sed: fix for the segfault

[Alan Curry]

Package: sed
Version: 4.1.2-8
Followup-For: Bug #273008

This bug was introduced upstream in sed-4.0e. The following patch seems to
fix it. Patch is for 4.1.4 but should apply fairly easily to any version from
4.0e up.

diff -ru sed-4.1.4/sed/execute.c sed-4.1.4.pac/sed/execute.c
--- sed-4.1.4/sed/execute.c 2004-12-26 09:56:41.0 -0500
+++ sed-4.1.4.pac/sed/execute.c 2005-10-02 02:15:07.0 -0500
@@ -738,8 +738,7 @@
 
   for (cur_cmd = vec->v, n = vec->v_length; n--; cur_cmd++)
 if (cur_cmd->a1
-   && (cur_cmd->a1->addr_type == ADDR_IS_NUM
-   || cur_cmd->a1->addr_type == ADDR_IS_NUM_MOD)
+   && cur_cmd->a1->addr_type == ADDR_IS_NUM
&& cur_cmd->a1->addr_number == 0)
   cur_cmd->range_state = RANGE_ACTIVE;
 else

-- System Information:
Debian Release: 3.1
Architecture: powerpc (ppc)
Kernel: Linux 2.6.11-powerpc
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages sed depends on:
ii  libc6   2.3.2.ds1-22 GNU C Library: Shared libraries an

-- debconf-show failed


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#332508: lde: does not work at all on big-endian archs

[Alan Curry]

Package: lde
Version: 2.6.0-6
Severity: important

ext2 (and, I think, all the other filesystems supported by lde) is
little-endian on disk, even when the CPU is big-endian. lde-2.6.0 gets this
wrong in several places, including the attempt to identify the superblock's
magic number. On a big-endian system it always says there is no filesystem on
the device.

There is an lde-2.6.1 on sourceforge which contains a lot of byte-swapping
fixes.

-- System Information:
Debian Release: 3.1
Architecture: powerpc (ppc)
Kernel: Linux 2.6.11-powerpc
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

-- debconf-show failed


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#327327: tcpick: does not run on ppc

[Alan Curry]

Package: tcpick
Version: 0.2.1-1
Severity: important
Tags: patch

On the ppc C compiler, char is an unsigned data type. This means that
no variable of type char can ever compare equal to the int value -1. gcc
tries to warn you about this when you compile tcpick, by saying:

args.c:195: warning: comparison is always true due to limited range of data type

tcpick therefore never makes it past the getopt loop. The following
patch fixes the problem.

diff -ru tcpick-0.2.1/src/args.c tcpick-0.2.1.pac/src/args.c
--- tcpick-0.2.1/src/args.c 2005-09-09 01:21:07.0 -0500
+++ tcpick-0.2.1.pac/src/args.c 2005-09-09 01:51:35.0 -0500
@@ -149,7 +149,7 @@
 void
 parse_args(int argc, char ** argv)
 {
-   char opt;
+   int opt;
 
 #ifdef HAVE_GETOPT_LONG
static struct option long_options[]=


-- System Information:
Debian Release: 3.1
Architecture: powerpc (ppc)
Kernel: Linux 2.6.11-powerpc
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages tcpick depends on:
ii  libc6   2.3.2.ds1-22 GNU C Library: Shared libraries an
ii  libpcap0.8  0.8.3-5  System interface for user-level pa

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#333200: apt-get source: warn before truncating pre-existing files

[Alan Curry]

Package: apt
Version: 0.5.28.6
Severity: wishlist

If you already have one of the files needed by apt-get source, it can skip
the download, or resume the download if the existing file is smaller than the
one to be downloaded. After seeing this feature work a few times, I thought I
could count on it, until...

Having downloaded a large .orig.tar.gz over a slow connection, I used apt-get
source to finish the job (download the dsc and diff and extract them). This
time, it didn't skip the download of the existing file. It truncated the
existing file to 0 and started over. Ouch! When you're expecting an append,
truncation is a very unpleasant surprise.

The reason for this rudeness was that the mtime on the file didn't match what
was on the server. I didn't do the original download with an mtime-preserving
method. So now I have to ask: how valuable is that mtime comparison? Is it
not enough that I have a file of the correct size and name? Is it really
likely that a file named "xfree86_4.3.0.dfsg.1.orig.tar.gz" will be anything
but the correct file, and that the mtime will allow you to make the
distinction? I doubt it. Especially when the file is complete and matches the
md5sum in the .dsc file!

If the mtime comparison must be retained, there should at least be a warning
before a truncate, like this:

  Modification time of existing file xfree86_4.3.0.dfsg.1.orig.tar.gz
  does not match the corresponding file on the server. What shall I do?
  [U]se existing file (resume download if incomplete)
  [M]ove existing file out of the way before downloading
  [E]rase existing file
  [U/m/e] _

Or even this would be an improvement:
  Modification time of existing file xfree86_4.3.0.dfsg.1.orig.tar.gz
  does not match the corresponding file on the server. Existing file
  contents will be lost. If you value this file, press ctrl-C NOW!
then sleep(5) before the truncate

There is a better way to deal with resumed downloads when there's a chance
the file contents won't match: subtract a few K from the resume point and
compare what you get to what's at the end of the existing file. This doesn't
require any special server support and wouldn't need anything like the kludge
of utime'ing the file on SIGINT.

-- Package-specific info:

-- System Information:
Debian Release: 3.1
Architecture: powerpc (ppc)
Kernel: Linux 2.6.11-powerpc
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages apt depends on:
ii  libc6   2.3.2.ds1-22 GNU C Library: Shared libraries an
ii  libgcc1 1:3.4.3-13   GCC support library
ii  libstdc++5  1:3.3.5-13   The GNU Standard C++ Library v3

-- debconf-show failed


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#239134: PATCH: jpeg and ppm support for xjig

[Alan Curry]

Nathanael Nerode writes the following:
>
>The GIF patent means that tools for turning things *into* gifs are pretty
>damn hard to find on a Debian system.

I don't believe it's true that GIFs are hard to make (djpeg, ppmtogif, etc.).
They're just not compressed.

But the point is valid anyway. xjig should support more image formats, so you
don't have to make intermediate gifs.

>
>So how about supporting PNG, which isn't that different, but which is much
>easier to convert to on Debian systems?  :-)
>

I've made a patch which implements JPEG and PPM support.

Because it was originally designed to work exclusively with GIFs, xjig uses
an internal image representation based on a 256-color palette. I haven't yet
attempted to change that internal representation, so JPEGs and PPMs are
quantized down to 256 colors.

Thanks to libjpeg, quantized JPEGs look good.

Quantized PPMs look horrible, because libnetpbm doesn't include a quantize
routine. I just crammed the colors into 8 bits by using 3 bits red, 3 bits
green, 2 bits blue.

No PNG yet. libpng's documentation is frightening. (And I don't see any
quantize routine in there either.)

The patch is kind of big for a mail message, so find it at


The size of the patch includes a lot of chunks that were moved from one file
to another, and a couple of files that were renamed, and some data types
renamed, all of which reflects the fact that there is now a generic
format-independent layer where previously there was just one image loader
which was partly GIF-dependent and partly format-independent. The amount of
new code is actually small.

This patch contains a couple of unrelated build fixes in the Imakefile and
Makefile.Linux. I couldn't get the build to work without these.

Diffed against Debian's version 2.4-8 (what I currently get with apt-get
source xjig), but it also applies to and works with the 2.4 orig.tar.gz. I
have not made any adjustments to the debian/* files. It will at least need
some new Build-Depends (libnetpbm-dev and libjpeg-dev).

Is there any active upstream maintainer for xjig? I'm going to be optimistic
and Cc: [EMAIL PROTECTED] whose address is in the source (next to some
9-year-old timestamps).


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#403709: nss_compat: infinite retrying of read errors

[Alan Curry]

Package: libc6
Version: 2.3.2.ds1-22sarge4
Severity: minor

Due to a recent power failure, my /etc/shadow file morphed into a directory.
You can probably guess that this made it difficult to log in. You might not
guess the symptom: instead of reporting an authentication failure in the
normal way, any attempt to log in causes a long pause with lots of disk
activity. That's because getspnam() gets stuck in an infinite loop allocating
memory and ends up swapping. No one expected the Spanish Inquisition^W^W^W^H
an EISDIR on /etc/shadow.

After poking around the source a bit, and recreating the incident in a
chroot, I suspect but haven't proven that the cause is in
compat-spwd.c:getspent_next_file which returns NSS_STATUS_TRYAGAIN in case of
read error. What exactly is NSS_STATUS_TRYAGAIN supposed to mean? Apparently
in this case it means "try again as many times as you can, as fast as you
can".

Oh, I just got an idea for another test: fgetspent. And it does the same
infinite memory-eating thing, in spite of not using NSS at all!

#include 
#include 

int main(void)
{
  FILE *fp;
  struct spwd *sp;
  fp=fopen(".", "r");
  if(!fp) {
perror("fopen(.)");
return 1;
  }
  sp=fgetspent(fp);
  return 0;
}

Also bombs with fgetpwent and fgetgrent. I suspect it'll do the same with any
read error, not just EISDIR. They all get translated to ERANGE for some
reason, which is then taken as meaning "You need to malloc some more and try
again". Ouch.

nss_files seems to be the only one who got this right.


-- System Information:
Debian Release: 3.1
Architecture: powerpc (ppc)
Kernel: Linux 2.6.17.6
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages libc6 depends on:
ii  libdb1-compat 2.1.3-7The Berkeley database routines [gl

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#357091: Issues w/ closed descriptors in dash

[Alan Curry]

Rainer Weikusat writes the following:
>
>@@ -342,7 +348,8 @@
>   if (rp->renamed[i] != EMPTY) {
>   if (!drop) {
>   close(i);
>-  copyfd(rp->renamed[i], i);
>+  if (rp->renamed[i] != CLOSEFD)
>+  copyfd(rp->renamed[i], i);
>   }
>   close(rp->renamed[i]);

This last close should also be protected by if(rp->renamed[i]!=CLOSEFD) to
avoid calling close(-3)

>   }
>

-- 
Alan Curry
[EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#406266: debsums: blocking open is a problem

[Alan Curry]

Package: debsums
Version: 2.0.16
Severity: minor
Tags: patch

After a "run fsck manually" episode, I knew I'd need to reinstall some
packages. I ran debsums to get a quick listing of what packages were messed
up. But it wasn't quick at all. It sat there for a long time not producing
output. Eventually I dceided something was wrong. It wasn't using any CPU and
the disk wasn't busy, and I knew debsums wouldn't normally take this long.

fsck had fixed several files, and one of them got "fixed" real good - it went
from being a normal boring man page to being a named pipe (prwS--S-wT or some
such nonsense). debsums was blocked trying to open it because, as you might
expect, there were no writers. I wouldn't have figured this out if it hadn't
been for strace -p `pidof debsums`

In case this happens to anyone else, I suggest that debsums should either
use a non-blocking open or stat the file before opening to make sure it's a
regular file. Named pipe isn't the worst case. It could have been a block or
character device with unpleasant side effects on being opened (and read, if
the open succeeded).

Here's a patch that does stat-before-open.

--- debsums.orig2007-01-09 17:05:41.0 -0500
+++ debsums 2007-01-09 17:05:44.0 -0500
@@ -234,6 +234,12 @@
$path = $diversion{$path}[0] if exists $diversion{$path}
and $diversion{$path}[1] ne $pack;
 
+   if (-e "$root/$path" && !-f _)
+   {
+   warn "$self: not regular file: $pack file $root/$path\n";
+   return 0;
+   }
+
unless (open F, "$root/$path")
{
return 0 if $localepurge

-- System Information:
Debian Release: 3.1
Architecture: powerpc (ppc)
Kernel: Linux 2.6.17.6
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages debsums depends on:
ii  debconf [debconf-2.0]  1.4.30.13 Debian configuration management sy
ii  perl   5.8.4-8sarge5 Larry Wall's Practical Extraction 

-- debconf information:
  debsums/apt-autogen: true


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#406880: unifdef: what about unifdefall?

[Alan Curry]

Package: unifdef
Version: 1.0+20030701-1
Severity: wishlist

Why isn't unifdefall installed with this package? It only needs slight
modification to remove the BSD-isms. I got it to run by:

1. adding .XX to the mktemp template

and

2. changing all the sed -E's to sed -r's

-- System Information:
Debian Release: 3.1
Architecture: powerpc (ppc)
Kernel: Linux 2.6.17.6
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages unifdef depends on:
ii  libc6 2.3.2.ds1-22sarge4 GNU C Library: Shared libraries an

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#414222: tzdata: please update to upstream version 2007c

[Alan Curry]

Package: tzdata
Version: 2007b-1
Severity: minor

Pulaski County, Indiana, which switched to Central time zone last year during
the Indiana daylight savings shake-up, have changed their minds. This year
they're coming back to Eastern. tzdata 2007c contains this change.

I'm unable to confirm the existence of any Debian installations in Pulaski
County (I live one county over), and it's probably too late now to get the
update pushed out before the switch happens (it's about 30 hours away as I
write this). Sorry I didn't notice sooner...



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#419619: gsfonts: postinst/prerm echo -e

[Alan Curry]

Package: gsfonts
Version: 1:8.11+urwcyr1.0.7~pre41-1
Severity: minor

The use of echo -e to enable backslash escapes is not supported by all shells
which may be installed as /bin/sh in Debian. When /bin/sh is [d]ash, the
upgrade of gsfonts prints some weird-looking messages like this:

  -e -n Unregistering PostScript fonts...
  -e -n (Re-)registering PostScript fonts...

The postinst and prerm scripts have these interesting lines:

  gsfonts.postinst:
  echo -e -n "(Re-)registering PostScript fonts...\n"

  gsfonts.prerm:
  echo -e -n "Unregistering PostScript fonts...\n"

They use 3 non-portable echo features in one line (-e, -n, and \n) - only one
of which (the -n) is guaranteed by Debian to be supported in /bin/sh, and the
net effect, if all 3 of them happen to work, is that they cancel each other
out! How about simplifying those lines to

  echo "(Re-)registering PostScript fonts..."
  echo "Unregistering PostScript fonts..."

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.20.4
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages gsfonts depends on:
ii  defoma   0.11.10-0.1 Debian Font Manager -- automatic f

gsfonts recommends no packages.

-- debconf-show failed


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#389360: x11-common: Where did the man page X.7x from package xfree86-common go?

[Alan Curry]

Followup-For: Bug #389360
Package: x11-common
Version: 1:7.1.0-16

I wondered the same thing. Where did the man page X.7x from package
xfree86-common go? Thanks to apt-file, I found out that it went to package
xorg-docs, which should probably be Suggested by something so there's a
chance of getting it installed during an upgrade from sarge. Having the
system become less thoroughly documented as a result of an upgrade is not
good.

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.20.4
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages x11-common depends on:
ii  debconf [debconf-2.0] 1.5.11 Debian configuration management sy
ii  debianutils   2.17   Miscellaneous utilities specific t
ii  lsb-base  3.1-23.1   Linux Standard Base 3.1 init scrip

x11-common recommends no packages.

-- debconf-show failed


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#419832: zsh: expanding non-ASCII filenames with doesn't work

[Alan Curry]

Package: zsh
Version: 4.3.2-25
Severity: normal

In the following demonstration, the first  keypress inserted the $'\300'
for me. The second  keypress, typed immediately after the asterisk,
should expand the glob into $'\300' also, but instead it just erases the
asterisk, replacing it with nothing at all. If Return is pressed after the
tab, the cat is executed with no arguments and reads from the tty.

% ls -b
\300
% cat $'\300' 
This is the content of a file whose name is a single non-ASCII character
% cat *
This is the content of a file whose name is a single non-ASCII character
% cat *

If any files are present whose names are ASCII-only, the glob expands into a
list of those, with the non-ASCII files excluded from the list.

Previous versions of zsh, for example the one in sarge, handle this situation
better. (The $'\300' construct isn't used; instead the non-ASCII character is
passed through as-is to the terminal, which is not ideal but better than
completely refusing to expand certain filenames.)

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.20.4
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages zsh depends on:
ii  debconf [debconf-2.0]   1.5.11   Debian configuration management sy
ii  libc6   2.3.6.ds1-13 GNU C Library: Shared libraries
ii  libncurses5 5.5-5Shared libraries for terminal hand

Versions of packages zsh recommends:
ii  libcap1   1:1.10-14  support for getting/setting POSIX.
ii  libpcre3  6.7-1  Perl 5 Compatible Regular Expressi

-- debconf-show failed


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#419837: crack-attack: grabs sound device even when no sound files present

[Alan Curry]

Package: crack-attack
Version: 1.1.14-6
Severity: wishlist

If crack-attack can't find any sounds to play (because they're
non-free/non-distributable, and not installed) it would be polite to close
the sound device so other processes can use it.

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.20.4
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages crack-attack depends on:
ii  freeglut3   2.4.0-5  OpenGL Utility Toolkit
ii  libatk1.0-0 1.12.4-3 The ATK accessibility toolkit
ii  libc6   2.3.6.ds1-13 GNU C Library: Shared libraries
ii  libcairo2   1.2.4-4  The Cairo 2D vector graphics libra
ii  libfontconfig1  2.4.2-1.2generic font configuration library
ii  libgcc1 1:4.1.1-21   GCC support library
ii  libgl1-mesa-glx [libgl1]6.5.1-0.6A free implementation of the OpenG
ii  libglib2.0-02.12.4-2 The GLib library of C routines
ii  libglu1-mesa [libglu1]  6.5.1-0.6The OpenGL utility library (GLU)
ii  libgtk2.0-0 2.8.20-7 The GTK+ graphical user interface 
ii  libice6 1:1.0.1-2X11 Inter-Client Exchange library
ii  libpango1.0-0   1.14.8-5 Layout and rendering of internatio
ii  libsdl-mixer1.2 1.2.6-1.1+b2 mixer library for Simple DirectMed
ii  libsdl1.2debian 1.2.11-8 Simple DirectMedia Layer
ii  libsm6  1:1.0.1-3X11 Session Management library
ii  libstdc++6  4.1.1-21 The GNU Standard C++ Library v3
ii  libx11-62:1.0.3-7X11 client-side library
ii  libxcursor1 1.1.7-4  X cursor management library
ii  libxext61:1.0.1-2X11 miscellaneous extension librar
ii  libxfixes3  1:4.0.1-5X11 miscellaneous 'fixes' extensio
ii  libxi6  1:1.0.1-4X11 Input extension library
ii  libxinerama11:1.0.1-4.1  X11 Xinerama extension library
ii  libxmu6 1:1.0.2-2X11 miscellaneous utility library
ii  libxrandr2  2:1.1.0.2-5  X11 RandR extension library
ii  libxrender1 1:0.9.1-3X Rendering Extension client libra

crack-attack recommends no packages.

-- debconf-show failed


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#419936: glotski: minimums are not minimal

[Alan Curry]

Package: glotski
Version: 0.2-4
Severity: normal

In 3 of the levels that come with glotski, the displayed minimum number of
moves is wrong. See http://www.clss.net/~pacman/glotsol/ for my improved
solutions and the brute-force search program I used to find them (giving me
confidence that they are truly minimal.)

I reported this upstream a while ago and got nothing but a promise to look
into it.

This patch makes glotski display the true minimums.

diff -ru usrc/glotski-0.2/d18.lev psrc/glotski-0.2/d18.lev
--- glotski-0.2/d18.lev 2000-01-09 00:45:27.0 -0500
+++ glotski-0.2/d18.lev 2007-04-18 15:45:44.0 -0500
@@ -1,7 +1,7 @@
 ; D18 from _Sliding Piece Puzzles_
 ; Move big red block to lower right
 size 6 5
-step 75
+step 74
 ;
 initial
 AA89a.
diff -ru usrc/glotski-0.2/d19.lev psrc/glotski-0.2/d19.lev
--- glotski-0.2/d19.lev 2000-01-09 00:45:27.0 -0500
+++ glotski-0.2/d19.lev 2007-04-18 15:45:47.0 -0500
@@ -1,7 +1,7 @@
 ; D19 from _Sliding Piece Puzzles_
 ; Move big red block to lower right
 size 6 5
-step 99
+step 92
 ;
 initial
 AA1189
diff -ru usrc/glotski-0.2/d23.lev psrc/glotski-0.2/d23.lev
--- glotski-0.2/d23.lev 2000-01-09 00:45:27.0 -0500
+++ glotski-0.2/d23.lev 2007-04-18 15:45:51.0 -0500
@@ -1,7 +1,7 @@
 ; D23 from _Sliding Piece Puzzles_
 ; Move big red block to lower right
 size 6 5
-step 223
+step 199
 ;
 initial
 .11233

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.20.4
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages glotski depends on:
ii  gdk-imlib11.9.14-31  compatibility package for gdk-imli
ii  libart2   1.4.2-34   The GNOME canvas widget - runtime 
ii  libaudiofile0 0.2.6-6Open-source version of SGI's audio
ii  libc6 2.3.6.ds1-13   GNU C Library: Shared libraries
ii  libdb33.2.9+dfsg-0.1 Berkeley v3 Database Libraries [ru
ii  libesd0   0.2.36-3   Enlightened Sound Daemon - Shared 
ii  libglib1.21.2.10-17  The GLib library of C routines
ii  libgnome321.4.2-34   The GNOME libraries
ii  libgnomesupport0  1.4.2-34   The GNOME libraries (Support libra
ii  libgnomeui32  1.4.2-34   The GNOME libraries (User Interfac
ii  libgtk1.2 1.2.10-18  The GIMP Toolkit set of widgets fo
ii  libice6   1:1.0.1-2  X11 Inter-Client Exchange library
ii  libsm61:1.0.1-3  X11 Session Management library
ii  libx11-6  2:1.0.3-7  X11 client-side library
ii  libxext6  1:1.0.1-2  X11 miscellaneous extension librar
ii  libxi61:1.0.1-4  X11 Input extension library

glotski recommends no packages.

-- debconf-show failed


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#417528: Math::BigFloat: wrong result from sqrt

[Alan Curry]

Package: perl-modules
Version: 5.8.4-8sarge5
Severity: normal

$ perl -le 'print sqrt(sqrt(2)**3)'
1.68179283050743
$ perl -le 'use bignum; print sqrt(sqrt(2)**3)'
9.101797207145410796943657706576305980854
$ perl -le 'use bignum lib => "GMP"; print sqrt(sqrt(2)**3)'
1.681792830507429086062250952466429790081

-- System Information:
Debian Release: 3.1
Architecture: powerpc (ppc)
Kernel: Linux 2.6.20
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages perl-modules depends on:
ii  perl   5.8.4-8sarge5 Larry Wall's Practical Extraction 

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#389345: dc: man page formatting bug

[Alan Curry]

Package: dc
Version: 1.06-15
Severity: minor
Tags: patch

The -E option appears in dc(1) tacked on to the end of the preceding
paragraph, instead of directly above its equivalent --initexpr where it
should be.

--- doc/dc.1.orig   2006-09-25 01:37:59.0 -0500
+++ doc/dc.12006-09-25 01:38:03.0 -0500
@@ -80,6 +80,7 @@
 Add the commands in
 .I script
 to the set of commands to be run while processing the input.
+.TP
 .B -E \fIscript\fP
 .TP
 .BI --initexpr= script

-- System Information:
Debian Release: 3.1
Architecture: powerpc (ppc)
Kernel: Linux 2.6.17.6
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages dc depends on:
ii  libc6 2.3.2.ds1-22sarge4 GNU C Library: Shared libraries an

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#709373: kbd: loadkeys -d no longer works

[Alan Curry]

Package: kbd
Version: 1.15.3-9
Severity: normal

"loadkeys -d" is supposed to load the default keymap. Instead it loads stdin.

"loadkeys -d somefile" should load the default keymap, then somefile.

This patch fixes all the usage cases, I think, but the loop logic is getting
ugly so you might want to rework it.

Index: kbd-1.15.3/src/loadkeys.y
===
--- kbd-1.15.3.orig/src/loadkeys.y  2013-05-22 05:32:30.378879662 -0500
+++ kbd-1.15.3/src/loadkeys.y   2013-05-22 05:36:37.890876881 -0500
@@ -1163,7 +1163,8 @@
close(fd);
}
 
-   for (i = optind; argv[i]; i++) {
+   int did_optd = 0;
+   for (i = optind; optd || argv[i]; i++) {
FILE *f;
char *ev;
 
@@ -1177,8 +1178,10 @@
}
 
if (optd) {
+   --i;
/* first read default map - search starts in . */
optd = 0;
+   did_optd = 1;
if ((f = findfile(DEFMAP, dirpath, suffixes)) == NULL) {
fprintf(stderr, _("Cannot find %s\n"), DEFMAP);
exit(EXIT_FAILURE);
@@ -1199,7 +1202,7 @@
parse_keymap(f);
}
 
-   if (optind == argc) {
+   if (optind == argc && !did_optd) {
strcpy(pathname, "");
parse_keymap(stdin);
}

-- System Information:
Debian Release: 7.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.8.2+ (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages kbd depends on:
ii  libc6 2.13-38
ii  lsb-base  4.1+Debian8

Versions of packages kbd recommends:
ii  console-data  2:1.12-2

kbd suggests no packages.

-- Configuration Files:
/etc/kbd/config changed [not included]
/etc/kbd/remap [Errno 2] No such file or directory: u'/etc/kbd/remap'

-- 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#709373: closed by Michael Schutte (Re: Bug#709373: kbd: loadkeys -d no longer works)

[Alan Curry]

Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the kbd package:
> 
> #709373: kbd: loadkeys -d no longer works
> 
> It has been closed by Michael Schutte .
> 
> Thanks for your report and your work on the patch.  I?m afraid you?ll
> have to live with this in Wheezy.  kbd 1.15.4 has fixed this regression
> and 1.15.5 is already in Jessie, so I am closing this bug.

I reported a bug in the stable release. It's not fixed until it's fixed in
the stable release.

But you're going to leave it unfixed for a year or three, while pretending
that it doesn't exist.

This is not nice.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#629611: xserver-xorg: reproducible X server segfault

[Alan Curry]

Package: xserver-xorg
Version: 1:7.5+8
Severity: normal

I found an easy way to crash the X server: view a 1bpp image with xli, and
increase the size with the '>' key a few times.

After the first resize, there's a small area of junk on the screen, to the
left of the xli window. The junk area increases roughly in proportion with
the xli window. The crash coincides with the point where the xli window has
grown past the right edge of the screen.

It's possible that a bug in xli is causing it to draw in the wrong area, but
the server crash is a more serious problem regardless of xli's misbehavior.

Tested in isolation, with nothing but X server and xli, not even a window
manager. The resulting segfault and backtrace is in the stuff that reportbug
has included below.

-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Feb  8 18:15 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 1948864 Feb 19 10:00 /usr/bin/Xorg

VGA-compatible devices on PCI bus:
--
0001:01:08.0 VGA compatible controller [0300]: ATI Technologies Inc RV280 
[Radeon 9200 PRO] [1002:5960] (rev 01)

Xorg X server configuration file status:

-rw--- 1 root root 3981 Feb  8 22:05 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
---

/etc/X11/xorg.conf.d does not exist.

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 2.6.37+ (pacman@kosh) (gcc version 4.3.2 (Debian 4.3.2-1.1) ) 
#153 Thu Jan 13 19:44:49 GMT+5 2011

Xorg X server log files on system:
--
-rw--- 1 root root 42162 Feb 27  2009 /var/log/Xorg.2.log
-rw-r--r-- 1 root root 79544 Jun  7 22:52 /var/log/Xorg.0.log
-rw-r--r-- 1 root root 39634 Jun  7 23:17 /var/log/Xorg.1.log

Contents of most recent Xorg X server log file (/var/log/Xorg.1.log):
-
_XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6
_XSERVTransOpen: transport open failed for inet6/kosh:1
_XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6

X.Org X Server 1.7.7
Release Date: 2010-05-04
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.26-2-powerpc64 ppc Debian
Current Operating System: Linux kosh 2.6.37+ #153 Thu Jan 13 19:44:49 GMT+5 
2011 ppc
Kernel command line: root=/dev/hda3 vt.default_utf8=0
Build Date: 19 February 2011  02:44:42PM
xorg-server 2:1.7.7-13 (Cyril Brulebois ) 
Current version of pixman: 0.16.4
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.1.log", Time: Tue Jun  7 23:17:25 2011
(==) Using config file: "/etc/X11/xorg.conf"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
(==) ServerLayout "Default Layout"
(**) |-->Screen "Default Screen" (0)
(**) |   |-->Monitor "Generic Monitor"
(**) |   |-->Device "Generic Video Card"
(**) |-->Input Device "Generic Keyboard"
(**) |-->Input Device "Configured Mouse"
(==) Automatically adding devices
(==) Automatically enabling devices
(WW) `fonts.dir' not found (or not valid) in "/usr/X11R6/lib/X11/fonts/misc".
Entry deleted from font path.
(Run 'mkfontdir' on "/usr/X11R6/lib/X11/fonts/misc").
(WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
Entry deleted from font path.
(WW) The directory "/usr/X11R6/lib/X11/fonts/cyrillic" does not exist.
Entry deleted from font path.
(WW) `fonts.dir' not found (or not valid) in "/usr/X11R6/lib/X11/fonts/100dpi/".
Entry deleted from font path.
(Run 'mkfontdir' on "/usr/X11R6/lib/X11/fonts/100dpi/").
(WW) `fonts.dir' not found (or not valid) in "/usr/X11R6/lib/X11/fonts/75dpi/".
Entry deleted from font path.
(Run 'mkfontdir' on "/usr/X11R6/lib/X11/fonts/75dpi/").
(WW) `fonts.dir' not found (or not valid) in "/usr/X11R6/lib/X11/fonts/Type1".
Entry deleted from font path.
(Run 'mkfontdir' on "/usr/X11R6/lib/X11/fonts/Type1").
(WW) `fonts.dir' not found (or not valid) in "/usr/X11R6/lib/X11/fonts/100dpi".
Entry deleted from font path.
(Run 'mkfontdir' on "/usr/X11R6/lib/X11/fonts/100dpi").
(WW) `fonts.dir' not found (or not valid) in "/usr/X11R6/lib/X11/fonts/75dpi".
Entry deleted from font path.
(Run 'mkfontdir' on "/usr/X11R6/lib/X11/fonts/75dpi").
(WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
Entry deleted from font path.
(**) FontPath set to:
unix/:7100,
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscal

Bug#712099: less: try to do a backward search, get forward search instead

[Alan Curry]

Package: less
Version: 444-4
Severity: normal
Tags: upstream

Searching in less has gone wacky.

Run this:

  seq 100 | less

Search forward for "40":

  /40

Search backward for "9":

  ?9

I should be at 39. I'm at 59!

I've also noticed a new feature where if you search for the same thing twice
in a row, less stays on the first match and beeps instead of advancing to the
next match.

If not bugs, then these are insane new features, especially the one that
moves forward when I search backward. less is too old to be growing new
incompatible behaviors.

-- System Information:
Debian Release: 7.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.8.2+ (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages less depends on:
ii  debianutils  4.3.2
ii  libc62.13-38
ii  libtinfo55.9-10

less recommends no packages.

less 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#718604: libjpeg-progs: djpeg broken for some jpegs

[Alan Curry]

Package: libjpeg-progs
Version: 8d-1
Severity: normal
Tags: patch upstream

This report will mostly be a duplicate of #74087, closed almost 13 years
ago, without any explanation that I can find in the bug log, and without
actually fixing it as far as I can tell from the packages from that era
on archive.debian.org.

The problem now is as it was then: djpeg can't handle all jpegs. The
ones it doesn't handle are the ones encoded as YCCK or CMYK. The bug log
for #74087 doesn't mention YCCK or CMYK, so it's possible that the
problem just wasn't understood back then. But the sample included in the
original bug report is a YCCK jpeg.

This time, there's a patch. The patch has been seen before too, in a
slightly different form, targeted at libjpeg-turbo. It adds a couple of
conversion functions to the library, allowing clients like djpeg to get
RGB output regardless of the input.

  http://sourceforge.net/p/libjpeg-turbo/patches/15/

It was rejected there, but I hope history won't repeat itself here.
It makes no sense that djpeg (the Decode JPEG program from the de facto
JPEG reference implementation!) can't decode all jpegs. The people in
the libjpeg-turbo discussion didn't even seem to realize they were
deciding to keep their version of djpeg crippled forever.

The conversion code could be moved into djpeg, leaving the library
untouched, but djpeg isn't the only place something like this is needed.
I'd also like to see xli not choke on these jpegs.

If the conversion is supported by the library, then adding YCCK-jpeg
support to djpeg and xli is a 3-line patch for each program. 

If the conversion function is banned from the library like the
libjpeg-turbo people seem to want, xli and djpeg both need the same big
mess of pixel-shuffling code inserted into them, and so will the next
program. That's just a stupid way to do it.

Index: libjpeg8-8d/jdcolor.c
===
--- libjpeg8-8d.orig/jdcolor.c  2013-08-02 18:38:50.0 -0500
+++ libjpeg8-8d/jdcolor.c   2013-08-02 18:42:18.578891259 -0500
@@ -125,6 +125,105 @@
   }
 }
 
+/*
+ * Convert inverted CMYK to RGB
+ */
+METHODDEF(void)
+cmyk_rgb_convert (j_decompress_ptr cinfo,
+JSAMPIMAGE input_buf, JDIMENSION input_row,
+JSAMPARRAY output_buf, int num_rows)
+{
+  double c, m, y, k;
+  register JSAMPROW outptr;
+  register JSAMPROW inptr0, inptr1, inptr2, inptr3;
+  register JDIMENSION col;
+
+  JDIMENSION num_cols = cinfo->output_width;
+
+  while (--num_rows >= 0) {
+inptr0 = input_buf[0][input_row];
+inptr1 = input_buf[1][input_row];
+inptr2 = input_buf[2][input_row];
+inptr3 = input_buf[3][input_row];
+input_row++;
+outptr = *output_buf++;
+for (col = 0; col < num_cols; col++) {
+   c = (double) GETJSAMPLE(inptr0[col]);
+   m = (double) GETJSAMPLE(inptr1[col]);
+   y = (double) GETJSAMPLE(inptr2[col]);
+   k = (double) GETJSAMPLE(inptr3[col]);
+
+outptr[RGB_RED] =   (JSAMPLE)(c*k/255);
+outptr[RGB_GREEN] = (JSAMPLE)(m*k/255);
+outptr[RGB_BLUE] =  (JSAMPLE)(y*k/255);
+outptr += RGB_PIXELSIZE;
+}
+  }
+}
+
+/*
+ * Convert YCCK to RGB
+ */
+METHODDEF(void)
+ycck_rgb_convert (j_decompress_ptr cinfo,
+  JSAMPIMAGE input_buf, JDIMENSION input_row,
+  JSAMPARRAY output_buf, int num_rows)
+{
+  my_cconvert_ptr cconvert = (my_cconvert_ptr) cinfo->cconvert;
+  double cyan, magenta, yellow, black;
+  register int y, cb, cr;
+  register JSAMPROW outptr;
+  register JSAMPROW inptr0, inptr1, inptr2, inptr3;
+  register JDIMENSION col;
+  JDIMENSION num_cols = cinfo->output_width;
+
+  /* copy these pointers into registers if possible */
+  register JSAMPLE * range_limit = cinfo->sample_range_limit;
+  register int * Crrtab = cconvert->Cr_r_tab;
+  register int * Cbbtab = cconvert->Cb_b_tab;
+  register INT32 * Crgtab = cconvert->Cr_g_tab;
+  register INT32 * Cbgtab = cconvert->Cb_g_tab;
+  SHIFT_TEMPS
+
+  while (--num_rows >= 0) {
+inptr0 = input_buf[0][input_row];
+inptr1 = input_buf[1][input_row];
+inptr2 = input_buf[2][input_row];
+inptr3 = input_buf[3][input_row];
+input_row++;
+outptr = *output_buf++;
+for (col = 0; col < num_cols; col++) {
+
+
+  /* Read YCCK Pixel **/
+  y = GETJSAMPLE(inptr0[col]);
+  cb= GETJSAMPLE(inptr1[col]);
+  cr= GETJSAMPLE(inptr2[col]);
+ black = (double)GETJSAMPLE(inptr3[col]);
+
+  /* Convert  YCCK to CMYK  **/
+/* Range-limiting is essential due to noise introduced by DCT losses. 
*/
+  outptr[0] = range_limit[MAXJSAMPLE - (y + Crrtab[cr])];
+  outptr[1] = range_limit[MAXJSAMPLE - (y +
+ ((int) RIGHT_SHIFT(Cbgtab[cb] + Crgtab[cr], 
SCALEBITS)))];
+  outptr[2] = range_limit[MAXJSAMPLE - (y + Cbbtab[cb])];
+ /* K passes through unchanged */
+  outptr[3] = inptr3[col]; /* don't need GETJSAMPLE here

Bug#718604: libjpeg-progs: djpeg broken for some jpegs

[Alan Curry]

Bill Allombert wrote:
> 
> Dear Alan, I have forwarded your bug report to the upstream maintainer.
> Thanks for taking the time to work on this.
> 
> However, I have a question: how do you generate such JPEG images ?
> Would there be benefit for libjpeg to be able to do that ?

I gather from the archived libjpeg-turbo discussion that this weird kind of
jpeg is generated by Photoshop when certain options are enabled. I don't
know the motivation for creating them that way. I only wish I could take
arbitrary jpegs from the wild and feed them to a shell script based on
djpeg, without having the occasional failure because one of these YCCK
images showed up.

The second issue is that I'd also like to be able to run "xli *.jpg" in a
directory full of images-not-made-by-me, and not see any failures. That
means conversion needs to be done in xli or in the library. With the
patched version of the library, I already have xli working (by adding 3
extra lines to request RGB output from the library). Without the patched
library, it would be harder.

I can appreciate that the YCCK/CMYK formats are non-standard hacks forced
upon us by Adobe, and it's not pleasant to admit we need to support them.
But the free software community in general has not rejected them. They can
be converted by imagemagick, displayed by mozilla, and edited by gimp. The
only places where YCCK/CMYK support is missing is in the small and fast
alternatives to those programs. I want to fix that.

If we're stuck with a djpeg that refuses to decode images with proprietary
extensions, not because the extensions aren't understood but because the
maintainer objects to the existence of the extensions, then djpeg has
become more of a political object than a useful scripting tool.

After testing this patch, I became aware of jpegtopnm in the netpbm
package, which already handles YCCK. The easy way around this problem will
be to just s/djpeg/jpegtopnm/g in all my scripts and apt-get remove
libjpeg-progs.

But that leaves the followup issue, lack of xli support, unsolved. I'd then
have to port this patch (which inside libjpeg is *already working*) to xli.
And then xloadimage. And how about xpaint? Making each one of them contain
a duplicate of the conversion code would be ridiculous!

-- 
Alan Curry


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#718604: [rlw...@sdf.org: Bug#718604: libjpeg-progs: djpeg broken for some jpegs]

[Alan Curry]

Tom Lane wrote:
> 
> I took a quick look at the referenced Debian bug, and I'm in agreement
> with the "this is not a bug" position.  Although the complainant is of
> the opinion that djpeg should be able to read any JPEG file, that's
> utter nonsense.  It has never been intended to deal with CMYK data.
> The proposed patch involving somebody's hack-and-slash conversion to
> RGB just betrays complete ignorance of what CMYK is used for in the
> real world.  (I will note that I rejected similar patches back when

Here's what happens in the real world: on rare occasions, I encounter
jpeg files that I can't view because someone has put YCCK/CMYK in them.

I present you with a simplified version of the problem: forget djpeg;
ln -sf jpegtopnm /usr/bin/djpeg solved that. Now the only remaining
problem is that "xli *.jpg" randomly fails on a small percentage of
jpegs found in the wild. What's the correct solution to that?

xli is not going to have any information about the image except what it
gets from libjpeg. What should it display when libjpeg gives it CMYK
output? If I take the conversion formula from this proposed patch and put
it into xli instead, I'll have something satisfactory for the immediate
purpose. But putting the code in the library gives other programs the
opportunity to reuse it, and gives me identical results. How is that bad?

If the formula itself is bad, where's the correct one? What formula would
you use to display an image in a viewer that is dependent on libjpeg for
all of its information about the image, in the case that libjpeg produces
CMYK output?

-- 
Alan Curry


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#718604: [rlw...@sdf.org: Bug#718604: libjpeg-progs: djpeg broken for some jpegs]

[Alan Curry]

Bob Friesenhahn wrote:
> On Sat, 3 Aug 2013, Alan Curry wrote:
> >
> > If the formula itself is bad, where's the correct one? What formula would
> > you use to display an image in a viewer that is dependent on libjpeg for
> > all of its information about the image, in the case that libjpeg produces
> > CMYK output?
> 
> By definition, there is no one correct formula.  The approach which 
> works is to attach an ICC color profile to the JPEG which describes 
> its colorspace.  Then the viewer uses an ICC color profile describing 
> its own colorspace to transform from the origin colorspace to the 
> viewing colorspace.  These transforms may be accomplished via the 
> MIT/X11-licensed lcms library.
> 

You lose me already at "attach an ICC color profile". How does the
image viewer, relying on libjpeg to parse the file, find this attached
information? The words "attach", "ICC", and "profile" do not appear in
libjpeg.txt so I don't know how a client of the library is supposed to
access this metadata.

But I get the general outline: The function that maps input pixel values
to RGB is defined by some metadata in the jpeg which I don't know how to
find. Once I find it, I will pass it to liblcms for interpretation.

-- 
Alan Curry


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#718604: [rlw...@sdf.org: Bug#718604: libjpeg-progs: djpeg broken for some jpegs]

[Alan Curry]

Guido Vollbeding wrote:
[ Charset ISO-8859-1 unsupported, converting... ]
> Bob Friesenhahn wrote:
> 
> > You need to learn about how to do this other than via this private 
> > discussion.  It seems to be handled by storing a JPEG chunk with the 
> > computed ID JPEG_APP0+2.
> 
> Yes, this falls under the category which I call "color management system".
> This is an extensive topic and it will need some time to study
> before you get a sufficient understanding of the subject.
> In any case it exceeds by far the responsibilities of a core image codec.

I thought the responsibility of libjpeg was to encode and decode jpegs.
And I thought "decode" meant "give me pixels I can push to my screen", not
"make me parse the file myself to find metadata chunks".

Here's my growing list of programs in Debian that choke on YCCK jpegs,
and need to be individually modified if the library won't help out:

  aaphoto djpeg xjig xli xloadimage xpaint

And ones that do the "wrong" conversion (multiply the first 3 components
by the 4th component and divide by 255):

  jpegtopnm zgv

All would benefit if they could get RGB output from the library, without
needing to know about file format internals like APP0+2 markers.

-- 
Alan Curry


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#650792: excess spaces in wdiff of column-based files

[Alan Curry]

Package: wdiff
Version: 0.6.3-1
Severity: normal
Tags: upstream


wdiff produces some strange-looking output when comparing text aligned in
columns.

$ cat file1
A B
AAB
AAA   B
  B
A B
AAB
AAA   B
  B
A B
$ cat file2
A C
AAC
AAA   C
  C
A C
AAC
AAA   C
  C
A C
$ wdiff file1 file2
A [-B-] {+C+}
AA[-B-]{+C+}
AAA   [-B-]   {+C+}
  [-B-]  {+C+}
A [-B-] {+C+}
AA[-B-]{+C+}
AAA   [-B-]   {+C+}
  [-B-]  {+C+}
A [-B-] {+C+}
$

I can't think of any reasoning that supports the need for multiple spaces
after the [-B-], since the actual spaces in the input file are only to the
left of the B.

-- System Information:
Debian Release: 6.0.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: powerpc (ppc)

Kernel: Linux 3.0.3+
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages wdiff depends on:
ii  dpkg  1.15.8.11  Debian package management system
ii  install-info  4.13a.dfsg.1-6 Manage installed documentation in 
ii  libc6 2.11.2-10  Embedded GNU C Library: Shared lib
ii  libncurses5   5.7+20100313-5 shared libraries for terminal hand

wdiff recommends no packages.

wdiff 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#663938: xli: -geometry with negative offset is broken

[Alan Curry]

Package: xli
Version: 1.17.0+20061110-3
Severity: normal
Tags: patch


If you try to place an image in the lower right corner of the screen with
xli -geometry -0-0 it goes horribly wrong, with the window being almost
entirely off the screen.

This patch makes it behave better.

--- xli-1.17.0+20061110/window.c.orig   2012-03-14 00:12:45.0 -0500
+++ xli-1.17.0+20061110/window.c2012-03-14 00:15:39.0 -0500
@@ -508,6 +508,10 @@
if (winheight > DisplayHeight(disp, scrn) * 0.9)
winheight = DisplayHeight(disp, scrn) * 0.9;
}
+   if (user_geometry & XNegative)
+   winx -= winwidth;
+   if (user_geometry & YNegative)
+   winy -= winheight;
}
 
/* if the user told us to fit the colormap, we must use the default

-- System Information:
Debian Release: 6.0.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: powerpc (ppc)

Kernel: Linux 3.0.3+
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages xli depends on:
ii  libc6  2.11.3-3  Embedded GNU C Library: Shared lib
ii  libjpeg62  6b1-1 The Independent JPEG Group's JPEG 
ii  libpng12-0 1.2.44-1+squeeze2 PNG library - runtime
ii  libx11-6   2:1.3.3-4 X11 client-side library
ii  libxext6   2:1.1.2-1 X11 miscellaneous extension librar
ii  zlib1g 1:1.2.3.4.dfsg-3  compression library - runtime

xli recommends no packages.

xli 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#653073: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for

[Alan Curry]

jida...@jidanni.org writes:
> 
>   Filesystem 1K-blocksUsed 
> Available Use% Mounted on
>   rootfs   1071468  287940
> 729100  29% /
>   /dev/disk/by-uuid/551e44e1-2cad-42cf-a716-f2e6caf9dc78   1071468  287940
> 729100  29% /

(I'm replying only on the issue of the duplicate mount point. Someone else
can tackle the long ugly name.)

The one with "rootfs" as its device is the initramfs which you automatically
get with all recent kernels. Even if you aren't using an initramfs, there's
an empty one built into the kernel which gets mounted as the first root
filesystem. The real root gets mounted on top of that.

So this is a special case of a general problem with no easy solution: What
should df do when 2 filesystems are mounted at the same location? It can't
easily give correct information for both of them, since the later mount
obscures the earlier mount from view.

If there's a way for df to get the correct information for the lower mount, I
don't know what it would be. If you have a process with a leftover cwd or
open fd in the obscured filesystem, you can use that. But generally you
won't.

But maybe we could do better than reporting incorrectly that the lower mount
has size and usage identical to the upper mount! At least df could print a
warning at the end if it has seen any duplicate entries. Perhaps there is
some way it could figure out which one is on top, and print a bunch of
question marks as the lower mount's statistics.

If df is running as root, it might be able to unshare(2) the mount namespace,
unmount the upper level, and then statfs the mount point again to get the
correct results for the lower level. That won't work in all cases (even in a
private namespace you can't unmount the filesystem containing your own cwd)
and it does nothing for you if you're not root, but still... it would be a
cool bonus in the cases where it does work.

As a special case, "rootfs" should probably be excluded from the default
listing, since the initramfs is not very interesting most of the time. It
could still be shown with the -a option, although it would always have the
wrong statistics. Or if you really want to be impressive, default to showing
the initramfs if and only if it is the only thing mounted on "/" - so you can
run df within the initramfs before the real root is mounted and get the right
result.

Or... (brace yourself for the most bold idea yet)... can you imagine a kernel
interface that would *cleanly* give access to obscured mount points?

Comments on any of the above? Do the BSDs have any bright ideas we can steal,
or is their df as embarrassingly bad at handling obscured mount points as
ours?

-- 
Alan Curry



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#817859: gnutls-bin: man page formatting problems

[Alan Curry]

Package: gnutls-bin
Version: 3.3.8-6+deb8u3
Severity: minor

The man pages have some spurious "Fl"s in them. For example, in
gnutls-cli(1), one of the options appears to be:

   --tofu, - Fl -no-tofu

-- System Information:
Debian Release: 8.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.3.3+ (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages gnutls-bin depends on:
ii  libc6  2.19-18+deb8u3
ii  libgmp10   2:6.0.0+dfsg-6
ii  libgnutls-deb0-28  3.3.8-6+deb8u3
ii  libhogweed22.7.1-5
ii  libidn11   1.29-1+b2
ii  libnettle4 2.7.1-5
ii  libopts25  1:5.18.4-3
ii  libp11-kit00.20.7-1
ii  libtasn1-6 4.2-3+deb8u1
ii  zlib1g 1:1.2.8.dfsg-2+b1

gnutls-bin recommends no packages.

gnutls-bin suggests no packages.

-- no debconf information

Bug#419832: zsh: expanding non-ASCII filenames with

[Alan Curry]

Clint Adams writes the following:
>
>On Wed, Apr 18, 2007 at 02:31:42AM -0400, Alan Curry wrote:
>> In the following demonstration, the first  keypress inserted the $'\300'
>> for me. The second  keypress, typed immediately after the asterisk,
>> should expand the glob into $'\300' also, but instead it just erases the
>> asterisk, replacing it with nothing at all. If Return is pressed after the
>> tab, the cat is executed with no arguments and reads from the tty.
>
>> Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
>
>Non-ASCII characters don't exist in the C locale; maybe you want to pick
>a better one.
>

That's a pretty lame brush-off.

My locale is set correctly (to be precise, it is unset correctly; none of
those environment variables are set). It represents the type of output I want
to get from all programs that recognize locales: text in English if possible,
and traditional sort order, not that new-fangled chaotic LANG=en order, where
ls hides your Makefile in the middle of all your lowercase source files! (Why
do you think they made make(1) recognize Makefiles with a capital M? Because
it belongs at the start of the listing, that's why.)

If you think this behavior is justified, for what am I being punished? Using
the default ("C") locale? It accurately describes what language I can read.
Having a file that is not a valid sequence of characters in that locale?
Maybe I should go file bug reports on all the programs that allow me to
create a file with such a name. That will be a lot of bug reports.

Or maybe we could admit that regardless of one's preferred locale, it is
inevitable that one will occasionally obtain files whose names are not valid
character strings in that locale. It would be nice if our tools would not
choke on those, would it not?

The $'\300' notation is a vast improvement over what older zsh versions did,
just dump the wacky bytes directly to the terminal. The current version
already automatically inserts $'\300' when completing; I only suggest that it
behave identically when expanding.

Expanding a glob to an empty list, when in fact it matched something, surely
can't be considered acceptable behavior. Even worse if it matched several
things and only one of them had a nasty byte and got omitted, you might not
notice and then go ahead and act on the wrong set of files.

Come on.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#419832: zsh: expanding non-ASCII filenames with

[Alan Curry]

Here's a backtrace showing where the extra characters get lost during an
expand operation (touch a$'\300' and then cat a*)

#0  stringaszleline (instr=0x100e0850 "cat a\300", incs=6, outll=0xfc97658,
outsz=0xfc97890, outcs=0xfc97684) at zle_utils.c:244
#1  0x0fc70224 in unmetafy_line () at zle_tricky.c:979
#2  0x0fc74ac0 in docomplete (lst=3) at zle_tricky.c:870
#3  0x0fc7697c in expandorcompleteprefix (args=0x100e0850) at zle_tricky.c:2742
#4  0x0fc60870 in execzlefunc (func=0xfc94990, args=0xfc97614,
set_bindk=264861272) at zle_main.c:1261
#5  0x0fc60dbc in zlecore () at zle_main.c:1019
#6  0x0fc614cc in zleread (lp=, rp=,
flags=, context=)
at zle_main.c:1174
#7  0x1003df68 in inputline () at input.c:278
#8  0x1003e970 in ingetc () at input.c:214
#9  0x1003813c in ihgetc () at hist.c:240
#10 0x1004a70c in yylex () at lex.c:646
#11 0x100709d8 in parse_event () at parse.c:451
#12 0x1003c73c in loop (toplevel=1, justonce=0) at init.c:129
#13 0x1003d8cc in zsh_main (argc=,
argv=) at init.c:1347
#14 0x1000b410 in main (argc=269355088, argv=0x6) at ./main.c:93

stringaszleline() gets an MB_INVALID from mbrtowc and doesn't handle it well.

When doing completion instead of expanding, the string gets generated by
add_match_data, which handles MB_INVALID by generating the $'\300'
replacement string. Maybe stringaszleline should be doing that too.

-- 
Alan Curry
[EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#427587: aumix: lame error message

[Alan Curry]

Package: aumix
Version: 2.8-17
Severity: normal

If you are printing an error message after a failed system call, always
include strerror(errno). This rule is very easy to follow and can save users
a lot of guesswork.

Script started on Tue Jun  5 00:07:11 2007
$ aumix -v 100
aumix:  error opening mixer
$
Script done on Tue Jun  5 00:07:14 2007

What happened? Permission denied? No such file? No such device? I don't know,
because aumix didn't tell me!

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.21.1
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages aumix depends on:
ii  libc6   2.3.6.ds1-13 GNU C Library: Shared libraries
ii  libgpmg11.19.6-25General Purpose Mouse - shared lib
ii  libncurses5 5.5-5Shared libraries for terminal hand

aumix recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#312722: telnet 0 25 works again

[Alan Curry]

Followup-For: Bug #312722
Package: telnet

This bug no longer exists in the stable distribution. It was probably caused
and fixed by libc. Since nobody cared enough to push the fix into 3.1rX when
it was stable, I'm guessing there will be no interest in fixing it for
oldstable. It should be closed.

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.20.4
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages telnet depends on:
ii  libc6   2.3.6.ds1-13 GNU C Library: Shared libraries
ii  libgcc1 1:4.1.1-21   GCC support library
ii  libncurses5 5.5-5Shared libraries for terminal hand
ii  libstdc++6  4.1.1-21 The GNU Standard C++ Library v3
ii  netbase 4.29 Basic TCP/IP networking system

telnet recommends no packages.

-- debconf-show failed


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#370792: cp: --sparse=always loses tail-end sparseness

[Alan Curry]

Subject: cp: --sparse=always loses tail-end sparseness
Package: coreutils
Version: 5.2.1-2
Severity: minor
Tags: patch

cp --sparse=always fails to maximize sparseness when a file ends with a
partial block cotaining only zeros:

$ dd if=/dev/null of=sparse bs=32769 seek=1 count=0
0+0 records in
0+0 records out
0 bytes transferred in 0.001514 seconds (0 bytes/sec)
$ ls -ls sparse
0 -rw---  1 pacman users 32769 Jun  6 13:45 sparse
$ cp --sparse=always sparse sparse2
$ ls -ls sparse2
4 -rw---  1 pacman users 32769 Jun  6 13:46 sparse2
$

This is caused by an unnecessary write() before the ftruncate() which sets
the file size.

--- src/copy.c.orig 2006-06-06 13:58:23.0 -0500
+++ src/copy.c  2006-06-06 14:32:58.0 -0500
@@ -363,16 +363,15 @@
}
 }
 
-  /* If the file ends with a `hole', something needs to be written at
- the end.  Otherwise the kernel would truncate the file at the end
- of the last write operation.  */
+  /* If the file ends with a `hole' and ftruncate is not available,
+ something needs to be written at the end.  Otherwise the kernel would
+ truncate the file at the end of the last write operation.  */
 
   if (last_write_made_hole)
 {
 #if HAVE_FTRUNCATE
-  /* Write a null character and truncate it again.  */
-  if (full_write (dest_desc, "", 1) != 1
- || ftruncate (dest_desc, n_read_total) < 0)
+  /* ftruncate sets the file size, so there is no need for a write.  */
+  if (ftruncate (dest_desc, n_read_total) < 0)
 #else
   /* Seek backwards one character and write a null.  */
   if (lseek (dest_desc, (off_t) -1, SEEK_CUR) < 0L

-- System Information:
Debian Release: 3.1
Architecture: powerpc (ppc)
Kernel: Linux 2.6.16.14
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages coreutils depends on:
ii  libacl1   2.2.23-1   Access control list shared library
ii  libc6 2.3.2.ds1-22sarge3 GNU C Library: Shared libraries an

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#185100: backgammon: fix "can only make 1 move" bug

[Alan Curry]

This is a resend of a message that seems to have gotten lost in the guts of
the BTS. It's been a week and I haven't seen a bounce or a confirmation. I
did get the original Bcc sent by reportbug...

I wrote, about a week ago:

>Package: bsdgames
>Version: 2.17-1sarge1
>Followup-For: Bug #185100
>
>This patch fixes the problem reported in #185100 by making movallow() try
>again with dice swapped when it finds that there is no possible move with the
>second die after the first die was used to move a man off the bar.
>
>This bug is present in the oldest version of backgammon that I was able to
>find, posted to comp.sources.games in 1988, carrying the version information
>"Last updated on Saturday, January 11, 1986."
>
>For easy reproduction, here's a savegame representing the board in the
>original bug report. Just run "backgammon movallowtest" and try the move
>0-4,23-24 to see the results. One obstacle: the savegame format is not
>portable. It's just an array of ints. So I'm including two versions of
>movallowtest. The first one is 32-bit ints with MSB first. The second one is
>32-bit ints with LSB first.
>
>begin 600 movallowtest
>[EMAIL PROTECTED]@``
>M__[]
>M``(#"0#Q\0D.`00!
>[EMAIL PROTECTED](`
>`
>end
>
>begin 600 movallowtest
>M`0#]_O___P#^_O___P``
>M__[]``(`
>M```#"0#Q\?___PD.`00!`0``
>5`/[EMAIL PROTECTED](`
>`
>end
>
>diff -ru bsdgames-2.17.orig/backgammon/common_source/allow.c 
>bsdgames-2.17/backgammon/common_source/allow.c
>--- bsdgames-2.17.orig/backgammon/common_source/allow.c2003-12-16 
>21:47:37.0 -0500
>+++ bsdgames-2.17/backgammon/common_source/allow.c 2006-05-14 
>02:14:29.0 -0500
>@@ -83,8 +83,10 @@
>   p[i--] = bar;
>   if (p[i] != bar)
>   continue;
>-  else
>+  else if (d0)
>   break;
>+  swap;
>+  continue;
>   }
>   if (d0 || m == 4)
>   break;
>
>-- System Information:
>Debian Release: 3.1
>Architecture: powerpc (ppc)
>Kernel: Linux 2.6.11-powerpc
>Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
>
>Versions of packages bsdgames depends on:
>ii  libc6 2.3.2.ds1-22sarge3 GNU C Library: Shared libraries an
>ii  libgcc1   1:3.4.3-13 GCC support library
>ii  libncurses5   5.4-4  Shared libraries for terminal hand
>ii  libstdc++51:3.3.5-13 The GNU Standard C++ Library v3
>ii  wamerican [wordlist]  5-4American English dictionary words 
>ii  wbritish [wordlist]   5-4British English dictionary words f
>ii  wenglish  5-4American English dictionary words 
>
>-- no debconf information
>



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#368771: backgammon: computer player fails to move

[Alan Curry]

Package: bsdgames
Version: 2.17-1sarge1
Severity: normal
Tags: patch

This is a resend of another message (see #185100 for the first one) that
seems to have gotten lost in the guts of the BTS. It's been a week and I
haven't seen a bounce or a confirmation. I did get the original Bcc sent by
reportbug...

About a week ago, I wrote:
>Package: bsdgames
>Version: 2.17-1sarge1
>Severity: normal
>Tags: patch
>
>Backgammon has a bug when playing human vs. computer, where sometimes, near
>the end of the game as the computer player is removing his pieces from the
>board, it will fail to make a move. The computer player basically skips a
>turn.
>
>This bug is present in the oldest version of backgammon that I was able to
>find, posted to comp.sources.games in 1988, carrying the version information
>"Last updated on Saturday, January 11, 1986."
>
>For easy reproduction, here's a savegame which demonstrates the problem. In
>the saved position, the computer is playing White and has just rolled a 2 and
>a 1. There are 5 white men off the board and 10 on his inner table. When you
>run "backgammon nomovetest" you will see "White rolls 2 1 and moves 2-0,1-0"
>but none of the pieces actually move. There are still 10 white pieces on the
>board and it has become Red's turn.
>
>One obstacle: the savegame format is not portable. It's just an array of
>ints. So I'm including two versions of nomovetest. The first one is 32-bit
>ints with MSB first. The second one is 32-bit ints with LSB first.
>
>begin 600 nomovetest
>M`/[EMAIL PROTECTED]
>M``("`P``
>M`0`%!PH([EMAIL PROTECTED]'_
>5__\!`0(`
>`
>end
>
>begin 600 nomovetest
>M`/_Y_O___P``
>M``("`P``
>M`0`%!PH([EMAIL PROTECTED]
>5__\!`0(`
>`
>end
>
>This patch fixes the problem. I'm also throwing in a couple of fixes for bad
>English grammar in the tutorial text.
>
>diff -ruN --exclude '*.o' bsdgames-2.17.orig/backgammon/backgammon/move.c 
>bsdgames-2.17/backgammon/backgammon/move.c
>--- bsdgames-2.17.orig/backgammon/backgammon/move.c2004-01-27 
>15:52:07.0 -0500
>+++ bsdgames-2.17/backgammon/backgammon/move.c 2006-05-13 16:37:39.0 
>-0500
>@@ -152,6 +152,9 @@
>   trymove(0, 0);
>   pickmove();
> 
>+  if (d0)
>+  swap;
>+
>   /* print move */
>   writel(" and moves ");
>   for (i = 0; i < mvlim; i++) {
>diff -ruN --exclude '*.o' bsdgames-2.17.orig/backgammon/teachgammon/ttext1.c 
>bsdgames-2.17/backgammon/teachgammon/ttext1.c
>--- bsdgames-2.17.orig/backgammon/teachgammon/ttext1.c 2003-12-16 
>21:47:37.0 -0500
>+++ bsdgames-2.17/backgammon/teachgammon/ttext1.c  2006-05-13 
>16:43:27.0 -0500
>@@ -94,7 +94,7 @@
>   "\n   Although not indicated on the board, the players' homes are",
>   "located just to the right of the board.  A player's men are placed",
>   "there when they are removed from the board.  The board you just",
>-  "saw was in it's initial position.  All games start with the board",
>+  "saw was in its initial position.  All games start with the board",
>   "looking like this.  Notice that red's pieces are represented by the",
>   "letter 'r' and white's pieces are represented by the letter 'w'.",
>   "Also, a position may have zero or more pieces on it, e.g.  posi-",
>diff -ruN --exclude '*.o' bsdgames-2.17.orig/backgammon/teachgammon/ttext2.c 
>bsdgames-2.17/backgammon/teachgammon/ttext2.c
>--- bsdgames-2.17.orig/backgammon/teachgammon/ttext2.c 2003-12-16 
>21:47:37.0 -0500
>+++ bsdgames-2.17/backgammon/teachgammon/ttext2.c  2006-05-13 
>16:54:41.0 -0500
>@@ -65,7 +65,7 @@
>   "points in a row) are difficult to form, many points nestled close-",
>   "ly together produce a formidable barrier.  Also, while it is good",
>   "to move back men forward, doing so lessens the opportunity for you",
>-  "to hit men.  Finally, remember that once the two player's have",
>+  "to hit men.  Finally, remember that once the two players have",
>   "passed each other on the board, there is no chance of either team",
>   "being hit, so the game reduces to a race off the board.  Addi-",
>   "tional hints on strategy are presented in the practice game.",
>
>-- System Information:
>Debian Release: 3.1
>Architecture: powerpc (ppc)
>Kernel: Linux 2.6.11-powerpc
>Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
>
>Versions of packages bsdgames depends on:
>ii  libc6 2.3.2.ds1-22sarge3 GNU C Library: Shared libraries an
>ii  libgcc1   1:3.4.3-13 GCC support library
>ii  libncurses5   5.4-4  Shared libraries for terminal hand
>ii  libstdc++51:3.3.5-13 The GNU Standard C++ Library v3
>ii  wamerican [wordli

Bug#369008: softbeep: bashism in sb-beep

[Alan Curry]

Package: softbeep
Version: 0.3-10
Severity: normal
Tags: patch

sb-beep is a #!/bin/sh script but uses the '==' operator in tests, which only
works with bash. softbeep needs this patch to work when /bin/sh is not bash:

--- softbeep-0.3/sb-beep.orig   2006-05-26 12:22:03.0 -0500
+++ softbeep-0.3/sb-beep2006-05-26 12:23:13.0 -0500
@@ -2,7 +2,7 @@
 
 FILE=/usr/share/sounds/warning.wav
 
-if [ "$1" == "irssi" ] || [ "$1" == "xchat" ] ; then
+if [ "$1" = "irssi" ] || [ "$1" = "xchat" ] ; then
FILE=/usr/share/sounds/email.wav
 fi
 

-- System Information:
Debian Release: 3.1
Architecture: powerpc (ppc)
Kernel: Linux 2.6.16.14
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages softbeep depends on:
ii  libc6 2.3.2.ds1-22sarge3 GNU C Library: Shared libraries an

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#369037: snarf: can't search google

[Alan Curry]

Package: snarf
Version: 7.0-3
Severity: normal
Tags: patch

$ snarf http://www.google.com/search\?q=futility
error: HTTP error from server: HTTP/1.0 403 Forbidden
$ snarf -z http://www.google.com/search\?q=futility
http://www.google.com/search?q=futility (unknown size)
search?q=futility [|]  14K
15052 bytes transferred in 2.63 sec (5.59k/sec)
$

Unbelievable. And these are the "don't be evil" people?

diff -u snarf-7.0.orig/http.c snarf-7.0/http.c
--- snarf-7.0.orig/http.c   2000-08-08 19:33:30.0 -0500
+++ snarf-7.0/http.c2006-05-26 17:47:14.0 -0500
@@ -222,6 +222,17 @@
 
 request = strconcat(request, "User-Agent: ", NULL);
 
+/* How silly of google to blacklist snarf by User-Agent.
+   Well, we can be silly too. */
+if (!(rsrc->options & (OPT_BE_MOZILLA|OPT_BE_MSIE))) {
+if (!strcmp(u->host, "google.com") ||
+(strlen(u->host) > strlen("google.com") &&
+ !strcmp(u->host+(strlen(u->host)-strlen("google.com"))-1,
+ ".google.com"))) {
+rsrc -> options |= OPT_BE_MOZILLA;
+}
+}
+
 if (getenv("SNARF_HTTP_USER_AGENT")) {
 request = strconcat(request, getenv("SNARF_HTTP_USER_AGENT"), 
 NULL);

-- System Information:
Debian Release: 3.1
Architecture: powerpc (ppc)
Kernel: Linux 2.6.16.14
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages snarf depends on:
ii  libc6 2.3.2.ds1-22sarge3 GNU C Library: Shared libraries an

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#369651: strace: show poll() parameters before blocking

[Alan Curry]

Package: strace
Version: 4.5.8-1.2
Severity: wishlist
Tags: patch

Ever since poll() started to become popular as a replacement for select(),
strace has been less useful than it used to be when we were living in a
select-based world. You can attach strace to a process while it's blocked in
select and find out which file descriptors it's waiting on, but with poll,
all you get is this:

  poll(

Nothing is revealed until after the poll is finished, which means strace
can't be used to find out why a poll never finishes.

This patch changes the format of poll traces to make them show as much useful
information as possible on entry to the syscall, like select. With the patch,
the part that gets printed immediately on entry looks like this:

  poll([{fd=0, events=POLLIN}, {fd=3, events=POLLIN}], 2, 2000

The revents are not shown in the first part because they are meaningless at
this stage. If the syscall completes successfully, the non-zero revents are
shown in a separate list after the return value.

Although reportbug insists on telling you that I have strace 4.5.8-1.2
installed (which is true since I am using Debian stable), this patch has been
made against a recent CVS version of strace, much closer to the 4.5.14-1
currently found in testing/unstable.

Index: stream.c
===
RCS file: /cvsroot/strace/strace/stream.c,v
retrieving revision 1.24
diff -u -r1.24 stream.c
--- stream.c1 Jun 2005 19:22:07 -   1.24
+++ stream.c30 May 2006 21:37:36 -
@@ -294,6 +294,30 @@
{ 0,NULL},
 };
 
+static char *
+sprintflags(xlat, flags)
+const struct xlat *xlat;
+int flags;
+{
+   static char outstr[1024];
+   char *sep;
+
+   outstr[0] = '\0';
+   sep = "";
+   for (; xlat->str; xlat++) {
+   if ((flags & xlat->val) == xlat->val) {
+   sprintf(outstr + strlen(outstr),
+   "%s%s", sep, xlat->str);
+   sep = "|";
+   flags &= ~xlat->val;
+   }
+   }
+   if (flags)
+   sprintf(outstr + strlen(outstr),
+   "%s%#x", sep, flags);
+   return outstr;
+}
+
 int
 sys_poll(tcp)
 struct tcb *tcp;
@@ -303,61 +327,131 @@
unsigned long size, start, cur, end, abbrev_end;
int failed = 0;
 
-   if (entering(tcp))
+   if (entering(tcp)) {
+   nfds = tcp->u_arg[1];
+   size = sizeof(fds) * nfds;
+   start = tcp->u_arg[0];
+   end = start + size;
+   if (nfds == 0 || size / sizeof(fds) != nfds || end < start) {
+   tprintf("%#lx, %d, %ld",
+   tcp->u_arg[0], nfds, tcp->u_arg[2]);
+   return 0;
+   }
+   if (abbrev(tcp)) {
+   abbrev_end = start + max_strlen * sizeof(fds);
+   if (abbrev_end < start)
+   abbrev_end = end;
+   } else {
+   abbrev_end = end;
+   }
+   tprintf("[");
+   for (cur = start; cur < end; cur += sizeof(fds)) {
+   if (cur > start)
+   tprintf(", ");
+   if (cur >= abbrev_end) {
+   tprintf("...");
+   break;
+   }
+   if (umoven(tcp, cur, sizeof fds, (char *) &fds) < 0) {
+   tprintf("?");
+   failed = 1;
+   break;
+   }
+   if (fds.fd < 0) {
+   tprintf("{fd=%d}", fds.fd);
+   continue;
+   }
+   tprintf("{fd=%d, events=", fds.fd);
+   printflags(pollflags, fds.events, "POLL???");
+   tprintf("}");
+   }
+   tprintf("]");
+   if (failed)
+   tprintf(" %#lx", start);
+   tprintf(", %d, ", nfds);
+#ifdef INFTIM
+   if (tcp->u_arg[2] == INFTIM)
+   tprintf("INFTIM");
+   else
+#endif
+   tprintf("%ld", tcp->u_arg[2]);
return 0;
+   } else {
+   static char outstr[1024];
+   char str[64], *flagstr;
+   unsigned int cumlen;
 
-   nfds = tcp->u_arg[1];
-   size = sizeof(fds) * nfds;
-   start = tcp->u_arg[0];
-   end = start + size;
-   if (nfds == 0 || size / sizeof(fds) != nfds || end < start) {
-   tprintf("%#lx, %d, %ld",
-   tcp->u_arg[0], nfds, tcp->u_arg[2]);
-   return 0;
-   }
-   if (abbrev(tcp)) {
-   abbrev_end = start + max_strlen * sizeof(fd

Bug#413768: fbi: autofirst bug patch

[Alan Curry]

Followup-For: Bug #413768
Package: fbi
Version: 2.05-2

Looks like a cut-and-paste coding error.

--- fbida-2.05.orig/fbiconfig.h.orig2007-05-02 17:16:02.0 -0500
+++ fbida-2.05/fbiconfig.h  2007-05-02 17:16:04.0 -0500
@@ -42,7 +42,7 @@
 
 #define GET_AUTO_UP()  cfg_get_bool(O_AUTO_UP,   0)
 #define GET_AUTO_DOWN()cfg_get_bool(O_AUTO_DOWN, 0)
-#define GET_AUTO_FIRST()   cfg_get_bool(O_AUTO_DOWN, 0)
+#define GET_AUTO_FIRST()   cfg_get_bool(O_AUTO_FIRST,0)
 #define GET_FIT_WIDTH()cfg_get_bool(O_FIT_WIDTH, 0)
 #define GET_QUIET()cfg_get_bool(O_QUIET, 0)
 #define GET_VERBOSE()  cfg_get_bool(O_VERBOSE,   1)


-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.20.4
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages fbi depends on:
ii  gs-gpl8.54.dfsg.1-5  The GPL Ghostscript PostScript int
ii  libc6 2.3.6.ds1-13   GNU C Library: Shared libraries
ii  libcurl3  7.15.5-1   Multi-protocol file transfer libra
ii  libexif12 0.6.13-5   library to parse EXIF files
ii  libfontconfig12.4.2-1.2  generic font configuration library
ii  libfreetype6  2.2.1-5FreeType 2 font engine, shared lib
ii  libjpeg62 6b-13  The Independent JPEG Group's JPEG 
ii  liblircclient00.8.0-9.2  LIRC client library
ii  libpcd2   1.0.1-1A library for reading PhotoCD imag
ii  libpng12-01.2.15~beta5-1 PNG library - runtime
ii  libtiff4  3.8.2-7Tag Image File Format (TIFF) libra
ii  libungif4g4.1.4-4shared library for GIF images
ii  zlib1g1:1.2.3-13 compression library - runtime

fbi recommends no packages.

-- debconf-show failed


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#442072: scrabble: won't let you play both blanks at once

[Alan Curry]

Package: scrabble
Version: 1.8-1
Severity: normal

So I had both blanks in my rack, and the Q and enough good stuff to score big
with it, but it wouldn't let me.

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.22.1
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

-- debconf-show failed



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#442821: scrabble: the change command is implemented incorrectly

[Alan Curry]

Package: scrabble
Version: 1.8-1
Severity: normal

I traded in the Q and got it back! That doesn't happen if the rules are
followed. First you set aside the tiles you're trading in. Then you draw
replacements from the pool. Then you return the set-aside tiles to the pool.

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.22.1
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

-- debconf-show failed



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#442072: scrabble: won't let you play both blanks at once

[Alan Curry]

Brian White writes the following:
>
>> So I had both blanks in my rack, and the Q and enough good stuff to score big
>> with it, but it wouldn't let me.
>
>Odd.  I've seen the computer play multiple blanks at once and so it 
>should allow it for players, too.  At what positions in the word were 
>the blanks located?  There's a restriction on computer play not to allow 
>two blanks in the first three letters in order to keep computation time 
>reasonable and I wonder if it got applied to the player, too.

I didn't keep a record of it, but it's happened twice. If we rigged the
random numbers, we could get 2 blanks and some nice friendly letters on the
first draw... Yeah, here we go.

 me:0  T R E E A _ _   you:0

You go first...
Enter word as "YXd " (Y=row, X=col, D=a/d) or "help" for other commands.
: 77a cheater
The word 'CHEATER' cannot be placed at location '77a'.
: 77a veteran
The word 'VETERAN' cannot be placed at location '77a'.
: 77a restate
The word 'RESTATE' cannot be placed at location '77a'.
: 77a earthen

You placed:
   60  EARThEn
for a total of 60 points.

chEATER would have required both blanks in the first 2 spots, but vETERAn
and REsTAtE (or REstATE) would have required only 1 out of the first 3.
EARThEn, with neither blank in the first 3 spaces, was accepted.

Random side note: I feel like I should have the option of choosing where the
blank goes when I play a word like "restate" with a real T and a blank T.

Random side note #2: I didn't realize when I sent these bug reports that
scrabble is no longer in Debian stable and it was only installed because it
was left over from before my last upgrade. I don't see what it could conflict
with, so I assume it was removed due to lack of interest, and the
availability of xscrabble and quackle, although neither of those is in etch
either. Sorry to make you think about bugs in abandonware, if that's what it
is.

Here's the random number rigging patch I used to do the above test.

--- /usr/games/scrabble 2005-03-26 18:15:20.0 -0500
+++ scrabble.rigged 2007-09-25 14:02:18.0 -0500
@@ -358,6 +358,13 @@
printf "  you:%-3d\n\n",$PScore;
 }
 
+my @rigged=qw/80 70 17 17 0 94 93 50 50 50 50 50 50 50 1/;
+sub riggedrand
+{
+  return shift @rigged if @rigged;
+  return rand($_[0]);
+}
+
 
 sub DrawLetters
 {
@@ -367,7 +374,7 @@
$count = 7 - length($$rack);
while ($count--) {
return if ($LRemain == 0);
-   $rand = int(rand($LRemain)) + 1;
+   $rand = int(riggedrand($LRemain)) + 1;
foreach $char (split(//,"ABCDEFGHIJKLMNOPQRSTUVWXYZ_*")) {
if ($char eq "*") {
print STDERR "Fatal: $LRemain letters remaining 
but Reserve is short\n";
@@ -1234,7 +1241,7 @@
 DisplayBoard();
 
 $Board[hex("77")] = "-";
-if (int(rand(2)) == 0) {
+if (int(riggedrand(2)) == 0) {
print "I go first...\n";
ComputerTurn(\$CLetters,\$CScore);
DrawLetters(\$CLetters);




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#442072: scrabble: won't let you play both blanks at once

[Alan Curry]

Brian White writes the following:
>
>> chEATER would have required both blanks in the first 2 spots, but vETERAn
>> and REsTAtE (or REstATE) would have required only 1 out of the first 3.
>> EARThEn, with neither blank in the first 3 spaces, was accepted.
>
>Thanks for doing all that testing.  I'll try to look at when I get a chance.
>
>
>> Sorry to make you think about bugs in abandonware, if that's what it
>> is.
>
>No, it was just renamed "scribble" to avoid any trademark infringements.

Oh. And the etch release got caught in the middle and ended up with neither
of them. So I'm using an old version with bugs that are fixed in lenny, but
because the name has changed, reportbug didn't warn me about using an
obsolete version or show me the current bugs in the "does your bug appear in
this list?" list. Now that I know to look at bugs.debian.org/scribble, it
seems like #311046 is the same thing.

The 1.10-2 .deb from testing/unstable installs clean on stable, and now my
test with rigged random numbers doesn't show the bug any more. So.. merge
with #311046 and close this bug.

-- 
Alan Curry
[EMAIL PROTECTED]



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#369651: strace: show poll() parameters before blocking

[Alan Curry]

Roland McGrath writes the following:
>
>Please send a patch relative to the current code (4.5.15).

Sorry for the delay. This patch is against current CVS as of a few minutes
ago.

Index: stream.c
===
RCS file: /cvsroot/strace/strace/stream.c,v
retrieving revision 1.26
diff -u -r1.26 stream.c
--- stream.c13 Dec 2006 16:59:45 -  1.26
+++ stream.c26 Aug 2007 22:44:54 -
@@ -296,6 +296,28 @@
{ 0,NULL},
 };
 
+static const char *
+sprintflags(const struct xlat *xlat, int flags)
+{
+   static char outstr[1024];
+   char *sep;
+
+   outstr[0] = '\0';
+   sep = "";
+   for (; xlat->str; xlat++) {
+   if ((flags & xlat->val) == xlat->val) {
+   sprintf(outstr + strlen(outstr),
+   "%s%s", sep, xlat->str);
+   sep = "|";
+   flags &= ~xlat->val;
+   }
+   }
+   if (flags)
+   sprintf(outstr + strlen(outstr),
+   "%s%#x", sep, flags);
+   return outstr;
+}
+
 static int
 decode_poll(struct tcb *tcp)
 {
@@ -304,62 +326,134 @@
unsigned long size, start, cur, end, abbrev_end;
int failed = 0;
 
-   if (entering(tcp))
-   return 0;
-
-   nfds = tcp->u_arg[1];
-   size = sizeof(fds) * nfds;
-   start = tcp->u_arg[0];
-   end = start + size;
-   if (nfds == 0 || size / sizeof(fds) != nfds || end < start) {
-   tprintf("%#lx, %d, ",
-   tcp->u_arg[0], nfds);
-   return 0;
-   }
-   if (abbrev(tcp)) {
-   abbrev_end = start + max_strlen * sizeof(fds);
-   if (abbrev_end < start)
+   if (entering(tcp)) {
+   nfds = tcp->u_arg[1];
+   size = sizeof(fds) * nfds;
+   start = tcp->u_arg[0];
+   end = start + size;
+   if (nfds == 0 || size / sizeof(fds) != nfds || end < start) {
+   tprintf("%#lx, %d, ",
+   tcp->u_arg[0], nfds);
+   return 0;
+   }
+   if (abbrev(tcp)) {
+   abbrev_end = start + max_strlen * sizeof(fds);
+   if (abbrev_end < start)
+   abbrev_end = end;
+   } else {
abbrev_end = end;
+   }
+   tprintf("[");
+   for (cur = start; cur < end; cur += sizeof(fds)) {
+   if (cur > start)
+   tprintf(", ");
+   if (cur >= abbrev_end) {
+   tprintf("...");
+   break;
+   }
+   if (umoven(tcp, cur, sizeof fds, (char *) &fds) < 0) {
+   tprintf("?");
+   failed = 1;
+   break;
+   }
+   if (fds.fd < 0) {
+   tprintf("{fd=%d}", fds.fd);
+   continue;
+   }
+   tprintf("{fd=%d, events=", fds.fd);
+   printflags(pollflags, fds.events, "POLL???");
+   tprintf("}");
+   }
+   tprintf("]");
+   if (failed)
+   tprintf(" %#lx", start);
+   tprintf(", %d, ", nfds);
+   return 0;
} else {
-   abbrev_end = end;
-   }
-   tprintf("[");
-   for (cur = start; cur < end; cur += sizeof(fds)) {
-   if (cur > start)
-   tprintf(", ");
-   if (cur >= abbrev_end) {
-   tprintf("...");
-   break;
+   static char outstr[1024];
+   char str[64];
+const char *flagstr;
+   unsigned int cumlen;
+
+   if (syserror(tcp))
+   return 0;
+   if (tcp->u_rval == 0) {
+   tcp->auxstr = "Timeout";
+   return RVAL_STR;
}
-   if (umoven(tcp, cur, sizeof fds, (char *) &fds) < 0) {
-   tprintf("?");
-   failed = 1;
-   break;
+
+   nfds = tcp->u_arg[1];
+   size = sizeof(fds) * nfds;
+   start = tcp->u_arg[0];
+   end = start + size;
+   if (nfds == 0 || size / sizeof(fds) != nfds || end < start)
+   return 0;
+   if (abbrev(tcp)) {
+   abbrev_end = start + max_strlen * sizeof(fds);
+   if (abbrev_end < start)
+   abbrev_end = end;
+   } else {
+

Bug#369651: strace: show poll() parameters before blocking

[Alan Curry]

Roland McGrath writes the following:
>
>Please post your patch to [EMAIL PROTECTED] for review.
>Standard form is to include ChangeLog entries before the patch.

OK, here it is. Updated to also provide the same benefit to ppoll().

2007-08-30  Alan Curry <[EMAIL PROTECTED]>

* stream.c (sprintflags): New function.
(decode_poll): Rearrange so that arguments are decoded and printed on
syscall entry, except for revents which are now printed in the auxstr.
(sys_poll): Print the timeout argument on syscall entry.
[LINUX] (sys_ppoll): Ditto.

Index: stream.c
===
RCS file: /cvsroot/strace/strace/stream.c,v
retrieving revision 1.26
diff -u -r1.26 stream.c
--- stream.c13 Dec 2006 16:59:45 -  1.26
+++ stream.c30 Aug 2007 23:40:13 -
@@ -296,6 +296,28 @@
{ 0,NULL},
 };
 
+static const char *
+sprintflags(const struct xlat *xlat, int flags)
+{
+   static char outstr[1024];
+   char *sep;
+
+   outstr[0] = '\0';
+   sep = "";
+   for (; xlat->str; xlat++) {
+   if ((flags & xlat->val) == xlat->val) {
+   sprintf(outstr + strlen(outstr),
+   "%s%s", sep, xlat->str);
+   sep = "|";
+   flags &= ~xlat->val;
+   }
+   }
+   if (flags)
+   sprintf(outstr + strlen(outstr),
+   "%s%#x", sep, flags);
+   return outstr;
+}
+
 static int
 decode_poll(struct tcb *tcp)
 {
@@ -304,62 +326,134 @@
unsigned long size, start, cur, end, abbrev_end;
int failed = 0;
 
-   if (entering(tcp))
-   return 0;
-
-   nfds = tcp->u_arg[1];
-   size = sizeof(fds) * nfds;
-   start = tcp->u_arg[0];
-   end = start + size;
-   if (nfds == 0 || size / sizeof(fds) != nfds || end < start) {
-   tprintf("%#lx, %d, ",
-   tcp->u_arg[0], nfds);
-   return 0;
-   }
-   if (abbrev(tcp)) {
-   abbrev_end = start + max_strlen * sizeof(fds);
-   if (abbrev_end < start)
+   if (entering(tcp)) {
+   nfds = tcp->u_arg[1];
+   size = sizeof(fds) * nfds;
+   start = tcp->u_arg[0];
+   end = start + size;
+   if (nfds == 0 || size / sizeof(fds) != nfds || end < start) {
+   tprintf("%#lx, %d, ",
+   tcp->u_arg[0], nfds);
+   return 0;
+   }
+   if (abbrev(tcp)) {
+   abbrev_end = start + max_strlen * sizeof(fds);
+   if (abbrev_end < start)
+   abbrev_end = end;
+   } else {
abbrev_end = end;
+   }
+   tprintf("[");
+   for (cur = start; cur < end; cur += sizeof(fds)) {
+   if (cur > start)
+   tprintf(", ");
+   if (cur >= abbrev_end) {
+   tprintf("...");
+   break;
+   }
+   if (umoven(tcp, cur, sizeof fds, (char *) &fds) < 0) {
+   tprintf("?");
+   failed = 1;
+   break;
+   }
+   if (fds.fd < 0) {
+   tprintf("{fd=%d}", fds.fd);
+   continue;
+   }
+   tprintf("{fd=%d, events=", fds.fd);
+   printflags(pollflags, fds.events, "POLL???");
+   tprintf("}");
+   }
+   tprintf("]");
+   if (failed)
+   tprintf(" %#lx", start);
+   tprintf(", %d, ", nfds);
+   return 0;
} else {
-   abbrev_end = end;
-   }
-   tprintf("[");
-   for (cur = start; cur < end; cur += sizeof(fds)) {
-   if (cur > start)
-   tprintf(", ");
-   if (cur >= abbrev_end) {
-   tprintf("...");
-   break;
+   static char outstr[1024];
+   char str[64];
+const char *flagstr;
+   unsigned int cumlen;
+
+   if (syserror(tcp))
+   return 0;
+   if (tcp->u_rval == 0) {
+   tcp->auxstr = "Timeout";
+  

Bug#370379: xserver-xorg-video-ati: here's a patch for the radeon stderr noise

[Alan Curry]

Followup-For: Bug #370379
Package: xserver-xorg-video-ati
Version: 1:6.6.3-2

--- src/radeon.h.orig   2007-05-18 01:13:05.0 -0500
+++ src/radeon.h2007-05-18 01:13:07.0 -0500
@@ -172,7 +172,7 @@
 
 /* - */
 
-#define RADEON_DEBUG1 /* Turn off debugging output   */
+#define RADEON_DEBUG0 /* Turn off debugging output   */
 #define RADEON_IDLE_RETRY  16 /* Fall out of idle loops after this count */
 #define RADEON_TIMEOUT200 /* Fall out of wait loops after this count */
 

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.21.1
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages xserver-xorg-video-ati depends on:
ii  libc6   2.3.6.ds1-13 GNU C Library: Shared libraries
ii  xserver-xorg-core   2:1.1.1-21   X.Org X server -- core server

xserver-xorg-video-ati recommends no packages.

-- debconf-show failed


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#429758: login: why have the default tty settings changed?

[Alan Curry]

Package: login
Version: 1:4.0.18.1-7
Severity: wishlist
Tags: patch

In previous versions of Debian (for example the 4.0.3-31sarge9 login
package), the default tty settings immediately after login include the
echoctl flag. That's the flag that causes the tty driver to print control
characters in the "caret" form, for example the Escape key is echoed as ^[
(caret left-bracket) and the up arrow key is echoed as ^[[A. Those caret
forms let the user know that his input is going to a program that is not
aware of control keys. It is then possible to use the erase character
(delete/backspace) to correct the mistake.

In the current stable version of login, the default tty flags have changed.
The most noticeable change, to me, has been the absence of echoctl. Without
echoctl, control characters received from the tty are echoed directly back to
the tty. This mode has its own interesting properties (for example, you can
run "cat >/dev/null" and type escape sequences to draw on the screen, and the
arrow keys directly cause cursor motion without any need to be interpreted
since ^[[A is both the up-arrow key on input and the cursor-up directive on
output) but in more realistic usage scenarios, this change has been annoying.

Without echoctl, if you accidentally type an escape-sequence-generating key
in a program that is using the default tty mode, the cursor may end up in the
wrong place, and the erase character can't get it back where it belongs so
you just give up and start over. Or you may type control-N and instead of
seeing "^N" you are now using the alternate character set. If you understand
what's going on, you can type ^O to get back to normal. Then you have to
backspace twice to get both of them out of the input buffer, even though you
can't see them.

The only entry in the upstream ChangeLog that seems relevant to this change
is "* src/login.c (setup_tty): remove dead code." but that code was not dead.
There was some dead code nearby, and it looks like someone just removed a bit
too much of setup_tty(). I can't be sure that's when it happened since
upstream versions are hard to get right now.

This patch restores the 4.0.3-31sarge9 version of setup_tty(), without the
dead code.

--- src/login.c.orig2007-06-19 16:24:21.0 -0500
+++ src/login.c 2007-06-19 15:33:50.0 -0500
@@ -175,6 +175,16 @@
termio.c_lflag |= ISIG | ICANON | ECHO | ECHOE;
termio.c_iflag |= ICRNL;
 
+#if defined(ECHOKE) && defined(ECHOCTL)
+   termio.c_lflag |= ECHOKE | ECHOCTL;
+#endif
+#if defined(ECHOPRT) && defined(NOFLSH) && defined(TOSTOP)
+   termio.c_lflag &= ~(ECHOPRT | NOFLSH | TOSTOP);
+#endif
+#ifdef ONLCR
+   termio.c_oflag |= ONLCR;
+#endif
+
/* leave these values unchanged if not specified in login.defs */
termio.c_cc[VERASE] = getdef_num ("ERASECHAR", termio.c_cc[VERASE]);
termio.c_cc[VKILL] = getdef_num ("KILLCHAR", termio.c_cc[VKILL]);

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.21.1
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages login depends on:
ii  libc6   2.3.6.ds1-13 GNU C Library: Shared libraries

login recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#542148: jwhois: connection failures

[Alan Curry]

Package: jwhois
Version: 4.0-1
Severity: normal
Tags: patch

With the current version of jwhois, I can't do IP address lookups. It fails
to connect to whois.arin.net, whois.ripe.net, and whois.apnic.net. These
lookups used to work with some older version (I'm not sure which).

The problem is in make_connect() in utils.c, the part that loops over the
list of results obtained from lookup_host_addrinfo(). After attempting to
make a connection, it does this:

  error = getsockopt(sockfd, SOL_SOCKET, SO_ERROR, &retval, &retlen);
  if (error < 0 || retval)
{
  break;
}

The intent was apparently to break out of the loop when a successful
connection occurs, but the retval test does the opposite, breaking out when a
connection fails.

With whois.arin.net for example, there are 2 IPv4 addresses and an IPv6
address. This loop connects to the first address successfully, so the
getsockopt results in error=0 retval=0, so it doesn't break. The next time
through the loop, it connects to the second address successfully, and doesn't
break. The third time, it fails to connect to the third address, because I
don't have IPv6. Now the loop ends and the function returns -1, failed to
connect, and the results look like this:

$ whois 199.232.41.10
[Querying whois.arin.net]
[Error creating socket]
[Unable to connect to remote host]

(Horrible error reporting, no strerror(errno) in it anywhere)

This patch gets it working again.

--- src/utils.c 2007-06-26 02:00:20.0 -0500
+++ src/utils.c 2009-08-17 23:35:09.0 -0500
@@ -288,7 +288,7 @@
 
   retlen = sizeof(retval);
   error = getsockopt(sockfd, SOL_SOCKET, SO_ERROR, &retval, &retlen);
-  if (error < 0 || retval)
+  if (error < 0 || !retval)
{
  break;
}

-- Syster Information:
Debian Release: 5.0.2
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: powerpc (ppc)

Kernel: Linux 2.6.30.2
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages jwhois depends on:
ii  adduser   3.110  add and remove users and groups
ii  dpkg  1.14.25Debian package management system
ii  libc6 2.7-18 GNU C Library: Shared libraries
ii  libgdbm3  1.8.3-3GNU dbm database routines (runtime

Versions of packages jwhois recommends:
pn  lynx   (no description available)

jwhois 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#550428: getaddrinfo: AI_CANNONAME should not do PTR lookups

[Alan Curry]

Package: libc6
Version: 2.7-18
Severity: normal


I'm reporting essentially a duplicate of this old bug:
  http://sources.redhat.com/bugzilla/show_bug.cgi?id=304

That bug is marked "resolved" but it clearly isn't resolved, since
getaddrinfo() still has a __gethostbyaddr_r() call in it (see
sysdeps/posix/getaddrinfo.c). This bug isn't resolved until that code is
dead! As far as I can tell, that code is still present in the newest glibc
and eglibc too.

Here's a little demonstration, with actual DNS records that exist today:

mail.gnu.org.   300 IN  A   199.232.76.166
166.76.232.199.in-addr.arpa. 23360 IN   CNAME   rev-c76-166.gnu.org.
rev-c76-166.gnu.org.300 IN  PTR mail.gnu.org.
rev-c76-166.gnu.org.300 IN  PTR mx10.gnu.org.
mx10.gnu.org.   300 IN  A   199.232.76.166

mail.gnu.org does not have a CNAME record. If you ask for the canonical name
of mail.gnu.org, the correct answer is mail.gnu.org. But glibc does a reverse
lookup, picks one of the PTRs at not-quite-random, and half the time you get
mx10.gnu.org instead:

$ cat canon.c
#include 
#include 
#include 

int main(void)
{
  struct addrinfo *res, hints={.ai_family=AF_INET, .ai_flags=AI_CANONNAME};
  int err;

  puts((err=getaddrinfo("mail.gnu.org", NULL, &hints, &res)) ?
   gai_strerror(err) : res->ai_canonname);
  return err;
}
$ cc canon.c -o canon
$ ./canon
mx10.gnu.org
$ ./canon
mail.gnu.org
$ ./canon
mx10.gnu.org

Neither mx10.gnu.org nor mail.gnu.org is the canonical name of the other. No
such relationship exists between those 2 names, and no such relationship can
ever be implied by any PTR records. glibc's behavior is completely bogus.

I believe a correct fix would be to reduce that entire block containing the
__gethostbyaddr_r() call to just these 2 lines:
  if (canon == NULL)
canon = orig_name;

But there's a sign that may not be enough. Each time I run the demo program
above, it generates the bogus PTR query twice. I wonder if removing the
__gethostbyaddr_r will take care of both of them, or if there's a similar bug
in the nss_dns module.

-- System Information:
Debian Release: 5.0.3
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: powerpc (ppc)

Kernel: Linux 2.6.31.2
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages libc6 depends on:
ii  libgcc1  1:4.3.2-1.1 GCC support library

libc6 recommends no packages.

Versions of packages libc6 suggests:
ii  glibc-doc 2.7-18 GNU C Library: Documentation
pn  locales(no description available)

-- debconf information:
* glibc/upgrade: true
  glibc/restart-failed:
* glibc/restart-services: rsync openbsd-inetd lpd cron atd



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#550807: wu-ftpd: addftpuser doesn't find ld.so

[Alan Curry]

Package: wu-ftpd
Version: 2.6.2-31~nopam0
Severity: normal

On architectures that never went through the a.out->ELF transition, the ELF
dynamic linker is called ld.so

For example I have these:
-rwxr-xr-x 1 root root 133784 Jan  4  2009 /lib/ld-2.7.so
lrwxrwxrwx 1 root root  9 Feb 15  2009 /lib/ld.so.1 -> ld-2.7.so

ldd /bin/gzip looks like this:
linux-vdso32.so.1 =>  (0x0010)
libc.so.6 => /lib/libc.so.6 (0x0fe7a000)
/lib/ld.so.1 (0x4800)

The /ld-linux/ regexps in addftpuser should probably something like
/ld-linux|ld\.so/

-- Package-specific info:
-- inetd packages installed

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
+++-==-==-
un  inetd-superser  (no description available)
un  inetutils-inet  (no description available)
un  libconfig-inet  (no description available)
un  micro-inetd (no description available)
rc  netkit-inetd   0.10-10The Internet Superserver
ii  openbsd-inetd  0.20080125-2   The OpenBSD Internet Superserver
un  rinetd  (no description available)
un  rlinetd (no description available)
ii  update-inetd   4.31   inetd configuration file updater
un  webmin-inetd(no description available)
un  wipl-client-in  (no description available)
un  xinetd  (no description available)

-- System Information:
Debian Release: 5.0.3
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: powerpc (ppc)

Kernel: Linux 2.6.31.2
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages wu-ftpd depends on:
ii  debconf [debconf-2.0]1.5.24  Debian configuration management sy
ii  debianutils  2.30Miscellaneous utilities specific t
ii  libc62.7-18  GNU C Library: Shared libraries
ii  perl [perl5] 5.10.0-19lenny2 Larry Wall's Practical Extraction 
ii  update-inetd 4.31inetd configuration file updater

wu-ftpd recommends no packages.

Versions of packages wu-ftpd suggests:
ii  logrotate 3.7.1-5Log rotation utility

-- debconf-show failed



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#551154: libc6-prof: undefined reference to `_dl_prof_resolve'

[Alan Curry]

Package: libc6-prof
Version: 2.7-18
Severity: important


$ cat myprog.c
int main(void)
{
  return 0;
}
$ gcc -g -pg -o myprog myprog.c -static-libgcc -lc_p
/usr/lib/gcc/powerpc-linux-gnu/4.3.2/../../../../lib/libc_p.a(dl-machine.op): 
In function `__elf_machine_runtime_setup':
(.text+0xd56): undefined reference to `_dl_prof_resolve'
/usr/lib/gcc/powerpc-linux-gnu/4.3.2/../../../../lib/libc_p.a(dl-machine.op): 
In function `__elf_machine_runtime_setup':
(.text+0xd5a): undefined reference to `_dl_prof_resolve'
collect2: ld returned 1 exit status
$

Note the gcc command line above is an exact copy of the example in
README.Debian, but it doesn't work. I can't find a way to get this
_dl_prof_resolve linked in. nm /lib/lib* /usr/lib/lib* finds it only in
/usr/lib/libc.a

I haven't made much of an effort to find out what _dl_prof_resolve is
supposed to do, but I did notice that it's defined in
sysdeps/powerpc/powerpc32/dl-trampoline.S, inside #ifndef PROF, which makes
me wonder, is that backwards? A function with "prof" in its name, that's
defined everywhere but the profiling library? Could I fix this by taking the
'n' out of #ifndef?

-- System Information:
Debian Release: 5.0.3
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: powerpc (ppc)

Kernel: Linux 2.6.31.2
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages libc6-prof depends on:
ii  libc6 2.7-18 GNU C Library: Shared libraries

libc6-prof recommends no packages.

libc6-prof suggests no packages.

-- debconf-show failed



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#434681: lslk: fails to list anything

[Alan Curry]

Package: lslk
Version: 1.29-3
Severity: important
Tags: patch

The function savelock() returns int, but the only return statements in it are
the ones that return 0 because of a failure. On success it just falls off the
end of the function returning some random left-over register value. This
random left-over value has a fairly good chance of being 0 (in fact it seems
to always be 0 in the ppc build.) Successes are interpreted as failures and
nothing gets printed.

Compiling with warnings enabled reveals a lot more questionable code, but
this fix at least gets it to print something.

/home/pacman/usrc/lslk-1.29/dialects/linux/proc/dlock.c
--- lslk-1.29.orig/dialects/linux/proc/dlock.c
+++ lslk-1.29/dialects/linux/proc/dlock.c
@@ -339,4 +339,5 @@
  * Set the lock source to local; Linux doesn't support remote locking.
  */
Lp->src = 0;
+   return 1;
 }

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.22.1
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages lslk depends on:
ii  libc6   2.3.6.ds1-13 GNU C Library: Shared libraries

lslk recommends no packages.

-- debconf-show failed


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#440768: xli: -zoom auto

[Alan Curry]

Package: xli
Version: 1.17.0-22
Severity: wishlist
Tags: patch

This patch implements the "-zoom auto" feature suggested in xli's TODO file.
It doesn't implement the related TODO item of merging -zoom and -iscale.

With -zoom auto, images smaller than 90% of the screen size are displayed
un-zoomed. Images larger than 90% of the screen size are reduced to fit.

diff -ruNp a/TODO b/TODO
--- a/TODO  2000-02-09 04:23:32.0 -0500
+++ b/TODO  2007-09-03 23:31:28.0 -0500
@@ -22,7 +22,6 @@ add vicar reader, copyright Noel Gorelic
 developed by NASA/JPL.'
 
 make fast image scaling a subfeature of -zoom, eliminate -iscale
-and add -zoom auto
 
 add a TIFF reader?
 
diff -ruNp a/xli.man b/xli.man
--- a/xli.man 2007-09-03 22:40:08.0 -0500
+++ b/xli.man 2007-09-04 00:02:38.0 -0500
@@ -317,6 +317,9 @@ more information.  Technically the perce
 square of the number supplied since the zoom is to both axes, but I
 opted for consistency instead of accuracy.
 .TP
+\-zoom auto
+Zoom large images to fit the screen; don't zoom small images.
+.TP
 \-newoptions
 Reset options that propagate.  The \fI\-bright, \-colors, \-colordither, 
\-delay,
 \-dither, \-gamma, \-gray, \-normalize, \-smooth, \-xzoom, \-yzoom\fR, and
diff -ruNp a/misc.c b/misc.c
--- a/misc.c2000-02-09 04:23:33.0 -0500
+++ b/misc.c2007-09-03 22:40:36.0 -0500
@@ -104,6 +104,8 @@ char *tail(char *path)
return (t);
 }
 
+#define MIN(a,b) ( (a)<(b) ? (a) : (b))
+
 Image *processImage(DisplayInfo *dinfo, Image *iimage, ImageOptions *options)
 {
Image *image = iimage, *tmpimage;
@@ -132,6 +134,19 @@ Image *processImage(DisplayInfo *dinfo, 
image = tmpimage;
}
/* zoom image */
+   if (options->zoom_auto) {
+   if (image->width > globals.dinfo.width * .9)
+   options->xzoom = globals.dinfo.width * 90 / 
image->width;
+   else
+   options->xzoom = 100;
+   if (image->height > globals.dinfo.height * .9)
+   options->yzoom = globals.dinfo.height * 90 / 
image->height;
+   else
+   options->yzoom = 100;
+   /* both dimensions should be shrunk by the same factor */
+   options->xzoom = options->yzoom =
+   MIN(options->xzoom, options->yzoom);
+   }
if (options->xzoom || options->yzoom) {
/* if the image is to be blown up, compress before doing it */
if (!options->colors && RGBP(image) &&  
diff -ruNp a/options.c b/options.c
--- a/options.c 1999-10-24 21:15:00.0 -0500
+++ b/options.c 2007-09-03 23:54:39.0 -0500
@@ -731,11 +731,16 @@ int doLocalOption(OptionId opid, char **
 
case ZOOM:
if (argv[++a]) {
-   if (atoi(argv[a]) < 0) {
-   printf("Zoom argument must be positive 
(ignored).\n");
-   break;
+   if (!strcmp(argv[a], "auto")) {
+image_ops->zoom_auto = TRUE;
+} else {
+   if (atoi(argv[a]) < 0) {
+   printf("Zoom argument must be positive 
(ignored).\n");
+   break;
+   }
+   image_ops->xzoom = image_ops->yzoom = 
atoi(argv[a]);
+   image_ops->zoom_auto = FALSE;
}
-   image_ops->xzoom = image_ops->yzoom = atoi(argv[a]);
if (setpersist)
persist_ops->xzoom = persist_ops->yzoom = 
image_ops->xzoom;
}
diff -ruNp a/xli.c b/xli.c
--- a/xli.c 2000-02-09 04:23:35.0 -0500
+++ b/xli.c 2007-09-03 22:40:36.0 -0500
@@ -541,6 +541,7 @@ int main(int argc, char *argv[])
break;
}
io->xzoom = io->yzoom = 0;
+   io->zoom_auto = 0;
io->iscale_auto = 0;
 
if (globals.verbose) {
diff -ruNp a/xli.h b/xli.h
--- a/xli.h 1999-10-24 21:15:07.0 -0500
+++ b/xli.h 2007-09-03 22:40:36.0 -0500
@@ -55,6 +55,7 @@ typedef struct {
char *title;/* Override title on image */
unsigned int xzoom, yzoom;
/* zoom percentages */
+   boolean zoom_auto;  /* automatically zoom to fit on screen */
char *fg, *bg;  /* foreground/background colors if mono image */
boolean done_to;/* TRUE if we have already looked for trailing
 * options

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to

Bug#440768: (xli -zoom auto) patch improvement

[Alan Curry]

Update: the first version of the patch didn't allow the -zoom auto option to
persist across multiple images. This version fixes that.

diff -ruNp a/TODO b/TODO
--- a/TODO  2000-02-09 04:23:32.0 -0500
+++ b/TODO  2007-09-03 23:31:28.0 -0500
@@ -22,7 +22,6 @@ add vicar reader, copyright Noel Gorelic
 developed by NASA/JPL.'
 
 make fast image scaling a subfeature of -zoom, eliminate -iscale
-and add -zoom auto
 
 add a TIFF reader?
 
diff -ruNp a/misc.c b/misc.c
--- a/misc.c2000-02-09 04:23:33.0 -0500
+++ b/misc.c2007-09-03 22:40:36.0 -0500
@@ -104,6 +104,8 @@ char *tail(char *path)
return (t);
 }
 
+#define MIN(a,b) ( (a)<(b) ? (a) : (b))
+
 Image *processImage(DisplayInfo *dinfo, Image *iimage, ImageOptions *options)
 {
Image *image = iimage, *tmpimage;
@@ -132,6 +134,19 @@ Image *processImage(DisplayInfo *dinfo, 
image = tmpimage;
}
/* zoom image */
+   if (options->zoom_auto) {
+   if (image->width > globals.dinfo.width * .9)
+   options->xzoom = globals.dinfo.width * 90 / 
image->width;
+   else
+   options->xzoom = 100;
+   if (image->height > globals.dinfo.height * .9)
+   options->yzoom = globals.dinfo.height * 90 / 
image->height;
+   else
+   options->yzoom = 100;
+   /* both dimensions should be shrunk by the same factor */
+   options->xzoom = options->yzoom =
+   MIN(options->xzoom, options->yzoom);
+   }
if (options->xzoom || options->yzoom) {
/* if the image is to be blown up, compress before doing it */
if (!options->colors && RGBP(image) &&  
diff -ruNp a/options.c b/options.c
--- a/options.c 1999-10-24 21:15:00.0 -0500
+++ b/options.c 2007-09-04 16:15:42.0 -0500
@@ -731,13 +731,20 @@ int doLocalOption(OptionId opid, char **
 
case ZOOM:
if (argv[++a]) {
-   if (atoi(argv[a]) < 0) {
-   printf("Zoom argument must be positive 
(ignored).\n");
-   break;
+   if (!strcmp(argv[a], "auto")) {
+image_ops->zoom_auto = TRUE;
+} else {
+   if (atoi(argv[a]) < 0) {
+   printf("Zoom argument must be positive 
(ignored).\n");
+   break;
+   }
+   image_ops->xzoom = image_ops->yzoom = 
atoi(argv[a]);
+   image_ops->zoom_auto = FALSE;
}
-   image_ops->xzoom = image_ops->yzoom = atoi(argv[a]);
-   if (setpersist)
+   if (setpersist) {
persist_ops->xzoom = persist_ops->yzoom = 
image_ops->xzoom;
+   persist_ops->zoom_auto = image_ops->zoom_auto;
+   }
}
break;
 
diff -ruNp a/xli.c b/xli.c
--- a/xli.c 2000-02-09 04:23:35.0 -0500
+++ b/xli.c 2007-09-04 16:32:12.0 -0500
@@ -90,6 +90,7 @@ int main(int argc, char *argv[])
persist_ops.xpmkeyc = 0;/* none */
persist_ops.xzoom = 0;
persist_ops.yzoom = 0;
+   persist_ops.zoom_auto = FALSE;
persist_ops.iscale = 0;
persist_ops.iscale_auto = FALSE;
 
@@ -201,6 +202,7 @@ int main(int argc, char *argv[])
images[nimages].xpmkeyc = persist_ops.xpmkeyc;
images[nimages].xzoom = persist_ops.xzoom;
images[nimages].yzoom = persist_ops.yzoom;
+   images[nimages].zoom_auto = persist_ops.zoom_auto;
images[nimages].iscale_auto = persist_ops.iscale_auto;
nimages++;
INIT_IMAGE_OPTS(images[nimages]);
@@ -541,6 +543,7 @@ int main(int argc, char *argv[])
break;
}
io->xzoom = io->yzoom = 0;
+   io->zoom_auto = 0;
io->iscale_auto = 0;
 
if (globals.verbose) {
diff -ruNp a/xli.h b/xli.h
--- a/xli.h 1999-10-24 21:15:07.0 -0500
+++ b/xli.h 2007-09-03 22:40:36.0 -0500
@@ -55,6 +55,7 @@ typedef struct {
char *title;/* Override title on image */
unsigned int xzoom, yzoom;
/* zoom percentages */
+   boolean zoom_auto;  /* automatically zoom to fit on screen */
char *fg, *bg;  /* foreground/background colors if mono image */
boolean done_to;/* TRUE if we have already looked for trailing
 * op

Bug#517485: manpages: console_ioctl(4) lies about KDGETLED

[Alan Curry]

Package: manpages
Severity: normal


This description:

>   KDGETLED
> Get state of LEDs.  argp points to a long.  The lower three bits
> of *argp are set to the state of the LEDs, as follows:
>
> LED_CAP   0x04   caps lock led
> LEC_NUM   0x02   num lock led
> LED_SCR   0x01   scroll lock led

is wrong. The kernel only stores a single byte *argp, so if you give it the
address of a long, you won't necessarily find the results in the low 3 bits
of the long. (It happens to work out that way if you are little-endian.)
Change "long" to "char" and the description will be correct.

Demonstration program (run it on a big-endian machine to see that the actual
behavior is not what the man page says):

#include 
#include 
#include 

int main(void)
{
  int ioctlret;
  long longval;

  longval = -1;

  ioctlret = ioctl(0, KDGETLED, &longval);
  printf("ioctlret=%d longval=%08lx\n", ioctlret, longval);

  return 0;
}

-- System Information:
Debian Release: 5.0
  APT prefers stable
  APT policy: (99, 'stable')
Architecture: powerpc (ppc)

Kernel: Linux 2.6.28.2
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

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



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#517619: tthsum: bad BIG_ENDIAN test. wrong hashes on big-endian arch.

[Alan Curry]

Package: tthsum
Version: 1.1.0-1
Severity: important


 defines BIG_ENDIAN to 4321 and LITTLE_ENDIAN to 1234, then defines
BYTE_ORDER to one or the other. The correct way to test them is like
  #if BYTE_ORDER == BIG_ENDIAN
tthsum does some other crazy stuff with those macros, and compiles the wrong
code at least on ppc and probably others too.

Try tthsum /dev/null on various machines.
VHBBPL5M64JQVJTIGMJTFTMHVO3FDFFIJELTBNY is the wrong answer.
LWPNACQDBZRYXW3VHJVCJ64QBZNGHOHHHZWCLNQ is the right answer.
The wrong answer is what I get on Debian stable ppc.

-- System Information:
Debian Release: 5.0
  APT prefers stable
  APT policy: (99, 'stable')
Architecture: powerpc (ppc)

Kernel: Linux 2.6.28.2
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages tthsum depends on:
ii  libc6 2.7-18 GNU C Library: Shared libraries

tthsum recommends no packages.

tthsum 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#480021: xserver-xorg-core: XKB failure: cause located, here's a patch

[Alan Curry]

Package: xserver-xorg-core
Version: 2:1.4.2-10
Followup-For: Bug #480021


The cause of this bug is that XkbCopyKeymap does a very incomplete job and
leaves a lot of zeros in the destination XkbGeometryRec. Later, that
defective XkbGeometryRec gets passed through XkbWriteXKBGeometry which
generates a defective xkbcomp input file. xkbcomp complains and fails, and
the server refuses to handle xkbset's requests.

The patch below enhances XkbCopyKeymap just enough to get rid of the xkbcomp
errors and warnings that occurred on my system, so xkbset could start working
again. I suspect that people with different keyboard settings will still have
problems because there are still a lot of fields that don't get copied by
XkbCopyKeymap.

--- xorg-server-1.4.2/xkb/xkbUtils.c2008-06-10 12:57:20.0 -0500
+++ xorg-server-1.4.2/xkb/xkbUtils.c2009-02-23 20:59:01.0 -0500
@@ -1699,6 +1699,8 @@
 
 dshape->num_outlines = sshape->num_outlines;
 dshape->sz_outlines = sshape->num_outlines;
+
+dshape->name = sshape->name;
 }
 
 dst->geom->num_shapes = src->geom->num_shapes;
@@ -1831,6 +1833,8 @@
 }
 dsection->num_doodads = ssection->num_doodads;
 dsection->sz_doodads = ssection->num_doodads;
+
+dsection->name = ssection->name;
 }
 }
 else {
@@ -1897,6 +1901,8 @@
 ddoodad->text.text = xstrdup(sdoodad->text.text);
 if (sdoodad->text.font)
 ddoodad->text.font = xstrdup(sdoodad->text.font);
+
+ddoodad->text.name = sdoodad->text.name;
 }
 else if (sdoodad->any.type == XkbLogoDoodad) {
 if (sdoodad->logo.logo_name)

-- Package-specific info:
Contents of /var/lib/x11/X.roster:

/var/lib/x11/X.md5sum does not exist.

X server symlink status:
lrwxrwxrwx 1 root root 13 Apr 11  2007 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 1950848 Jan  8 23:20 /usr/bin/Xorg

Contents of /var/lib/x11/xorg.conf.roster:
xserver-xorg

VGA-compatible devices on PCI bus:
0001:01:08.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 
PRO] (rev 01)

/etc/X11/xorg.conf does not match checksum in /var/lib/x11/xorg.conf.md5sum.

Xorg X server configuration file status:
-rw--- 1 root root 3761 Feb 22 02:24 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:


Xorg X server log files on system:
-rw--- 1 root root 45475 Jan 11  2008 /var/log/Xorg.2.log
-rw--- 1 root root 43630 Feb 23 15:33 /var/log/Xorg.0.log
-rw--- 1 root root 42099 Feb 23 20:28 /var/log/Xorg.1.log

Contents of most recent Xorg X server log file
/var/log/Xorg.1.log:


-- System Information:
Debian Release: 5.0
Architecture: powerpc (ppc)

Kernel: Linux 2.6.28.2
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages xserver-xorg-core depends on:
ii  libc62.7-18  GNU C Library: Shared libraries
ii  libdbus-1-3  1.2.1-5 simple interprocess messaging syst
ii  libdrm2  2.3.1-2 Userspace interface to kernel DRM 
ii  libfontenc1  1:1.0.4-3   X11 font encoding library
ii  libgcc1  1:4.3.2-1.1 GCC support library
ii  libhal1  0.5.11-8Hardware Abstraction Layer - share
ii  libpixman-1-00.10.0-2pixel-manipulation library for X a
ii  libxau6  1:1.0.3-3   X11 authorisation library
ii  libxdmcp61:1.0.2-3   X11 Display Manager Control Protoc
ii  libxfont11:1.3.3-1   X11 font rasterisation library
ii  x11-common   1:7.3+18X Window System (X.Org) infrastruc
ii  xserver-xorg 1:7.3+18the X.Org X server

Versions of packages xserver-xorg-core recommends:
ii  xfonts-base   1:1.0.0-5  standard fonts for X
ii  xkb-data  1.3-2  X Keyboard Extension (XKB) configu

Versions of packages xserver-xorg-core suggests:
ii  xfonts-100dpi 1:1.0.0-4  100 dpi fonts for X
ii  xfonts-75dpi  1:1.0.0-4  75 dpi fonts for X
ii  xfonts-scalable   1:1.0.0-6  scalable fonts for X

-- 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#603895: bug#7433: ls: [manual] description for --directory is insufficient

[Alan Curry]

Eric Blake writes:
> 
> The wording for -d may not mention it, but the wording at the very
> beginning of the --help and man page is clear that:
> 
> | Usage: ls [OPTION]... [FILE]...
> | List information about the FILEs (the current directory by default).

In other words, to correctly predict the behavior of "ls -d" you must
read two pieces of information that are not immediately adjacent to each
other, and use a minimal amount of thought to decide whether and how
they influence each other.

For people who read documentation all the way through, knowing that a
thorough understanding of the available tools will be a long-term
benefit, this is not a problem. Let's call these people the "smart
bears". They'll get the garbage can open easily because they're patient.

For people who only skim documentation, and not even that until they
have a problem, the obstacle is larger. If there isn't a single sentence
that tells them everything they need to know, they're not going to get
it. Let's call these people the "dumb tourists". They're impatient with
the garbage can latch, because they're holding a smelly bag of garbage.

Smart bears see a thick instruction manual and say "Hooray! Proper
documentation! I won't have to guess how it works." Dumb tourists see a
thick instruction manual and say "Screw that, reading sucks, I can guess
how it works."

man pages are written by and for smart bears. Dumb tourists don't write
documentation. Sometimes they write web pages which they optimistically
call "documentation".

Making documentation dumb-tourist-friendly inevitably makes it longer,
because it has to have a clause for each goal that the reader might want
to achieve, instead of just listing the facts and expecting the reader
to be able to put them together. The increased length bothers the smart
bears since it increases the time required to read the documentation
all the way through.

In the case of ls, I suggest that -d is special enough (since it affects
how the non-option arguments are used, unlike other ls options) that a
little extra length is justified. It would be reasonable to provide 2
separate SYNOPSIS lines, something like this:

SYNOPSIS
ls [OPTION]... [FILE]...
ls -d [OPTION]... [FILE]...

DESCRIPTION
The first form lists the given FILEs, and if any of them are
directories, the directory contents are listed. If no FILEs are
given, the contents of the current directory are listed.

The second form (with -d) lists the given FILEs, but any FILE
that is a directory will not have its contents listed. With no
FILEs given, the current directory (not its contents) is listed.

I don't care how you'd translate that to/from --help. I care about man
pages, not --help.

If that seems like giving too much attention to -d, how about this
alternative: add an EXAMPLES section. Dumb tourists love EXAMPLES
sections, and smart bears can safely skip them. It's a little bit
ridiculous that cat(1) has examples and ls(1) doesn't. ls has a lot more
options.

And the conflict between -R and -d should be explicitly mentioned. One
of them makes the other meaningless, and we should say which one.

-- 
Alan Curry



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#627376: vim: noshelltemp option truncates command output

[Alan Curry]

Package: vim
Version: 2:7.2.445+hg~cb94c42c0e1a-1
Severity: normal


This is a timing-sensitive bug, hard to reproduce. But after running into it
a few times, I finally came up with a simple test case that does the wrong
thing consistently for me. I hope this procedure makes it possible for others
to see it too:

Start up vim. :set noshelltmp. Insert the following long line into the edit
buffer:

sleep 3;printf '%s\n' xxx000 xxx001 xxx002 xxx003 xxx004 
xxx005 xxx006 xxx007 xxx008 xxx009 xxx010 xxx011 
xxx012 xxx013 xxx014 xxx015 xxx016 xxx017 xxx018

Run !!sh on that line. The command's output is truncated, with only a couple
of x's on the last line instead of xxx018. If you don't see the bug, try
a few more times, run a CPU-hogging program at the same time, and strace the
vim process. Anything that shakes up the timing can help bring out the bug.

I've been looking at mch_call_shell in os_unix.c, which is the likely
location of the bug, and I haven't figured everything out yet, but it looks
like the loops are ending prematurely. The inner while(RealWaitForChar(...))
loop could be ending because of the gettimeofday check (whose purpose I don't
understand, and this is made harder to study by the fact that strace no
longer shows gettimeofday!) Note that it has a 2 second threshold, and that I
used a sleep 3 to trigger the bug. I think those are related. With a sleep 1
instead I don't see the bug.

The outer for(;;) loop has a specific "Don't break the loop yet" comment
referring to "might still be something to read", but it doesn't seem to be
working since the loop is ended before everything has been read.

-- System Information:
Debian Release: 6.0.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: powerpc (ppc)

Kernel: Linux 2.6.37+
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages vim depends on:
ii  libacl1  2.2.49-4Access control list shared library
ii  libc62.11.2-10   Embedded GNU C Library: Shared lib
ii  libgpm2  1.20.4-3.3  General Purpose Mouse - shared lib
ii  libncurses5  5.7+20100313-5  shared libraries for terminal hand
ii  libselinux1  2.0.96-1SELinux runtime shared libraries
ii  vim-common   2:7.2.445+hg~cb94c42c0e1a-1 Vi IMproved - Common files
ii  vim-runtime  2:7.2.445+hg~cb94c42c0e1a-1 Vi IMproved - Runtime files

vim recommends no packages.

Versions of packages vim suggests:
ii  exuberant-ctags [ctags]  1:5.8-3squeeze1 build tag file indexes of source c
pn  vim-doc(no description available)
pn  vim-scripts(no description available)

-- 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#625259: libmagic1: where's my magic file?

[Alan Curry]

Package: file
Version: 5.04-5
Severity: normal

As far as I can tell, the new Debian release has removed the magic number
list that used to be called /usr/share/file/magic[1]. magic.mgc is all that's
left, and it's not human-readable.

It was nice to be able to get a judgement from file(1) and then find the
corresponding entry in the magic list and peek at the neighboring entries and
comments to learn more about the format. Now that's not possible.

/usr/share/file/magic is an empty directory, and I don't know why.

[1] and before that, used to be called /usr/share/misc/file/magic[2]

[2] and before bureaucratic nonsense took over, was called /etc/magic

-- System Information:
Debian Release: 6.0.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: powerpc (ppc)

Kernel: Linux 2.6.37+
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages libmagic1 depends on:
ii  libc6   2.11.2-10Embedded GNU C Library: Shared lib
ii  zlib1g  1:1.2.3.4.dfsg-3 compression library - runtime

libmagic1 recommends no packages.

Versions of packages libmagic1 suggests:
ii  file  5.04-5 Determines file type using "magic"

Versions of packages file depends on:
ii  libc6   2.11.2-10Embedded GNU C Library: Shared lib
ii  zlib1g  1:1.2.3.4.dfsg-3 compression library - runtime

-- 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