Bug#983504: firefox-esr: depends on wrong libnss3 version, TLS hangs with 2:3.58-1

[Adam M. Costello]

Package: firefox-esr
Version: 78.7.0esr-1
Severity: important

Dear Maintainer,

firefox-esr (both the latest version 78.8.0esr-1 and the latest testing
version 78.7.0esr-1) depends on libnss3 (>= 2:3.53.1~), but that is not
sufficient. https fails completely with libnss3 2:3.58-1.  It works with
2:3.61-1 (the current testing version).  I didn't try any other versions
of libnss3.

Evidence:

When I updated firefox-esr from 78.3.0esr-2 to 78.7.0esr-1, https
stopped working.  The firefox developer console showed that it was
making the TCP connection but not getting past the TLS setup.  I tried
several versions of firefox-esr:

78.8.0esr-1 broken
78.7.0esr-1 broken
78.6.1esr-1 broken
78.5.0esr-1 worked
78.3.0esr-2 worked

Eventually I suspected libnss3, which was at version 2:3.58-1 this whole
time.  I updated it to 2:3.61-1 (the current testing version), then
retried firefox-esr 78.7.0esr-1 (the current testing version), and that
worked.

-- Package-specific info:


-- Addons package information

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (600, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.16.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages firefox-esr depends on:
ii  debianutils  4.8.6
ii  fontconfig   2.13.0-5
ii  libatk1.0-0  2.36.0-2
ii  libc62.30-8
ii  libcairo-gobject21.15.10-3
ii  libcairo21.15.10-3
ii  libdbus-1-3  1.12.8-2
ii  libdbus-glib-1-2 0.110-2
ii  libevent-2.1-7   2.1.11-stable-1
ii  libffi7  3.3-4
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.2+dfsg-2
ii  libgcc-s110-20200304-1
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.64.3-2
ii  libgtk-3-0   3.24.20-1
ii  libnspr4 2:4.29-1
ii  libnss3  2:3.61-1
ii  libpango-1.0-0   1.44.7-4
ii  libstdc++6   10-20200304-1
ii  libvpx6  1.8.0-dmo2
ii  libx11-6 2:1.7.0-2
ii  libx11-xcb1  2:1.7.0-2
ii  libxcb-shm0  1.13-1
ii  libxcb1  1.13.1-2
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.4-3
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxrender1  1:0.9.10-1
ii  procps   2:3.3.15-1
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages firefox-esr recommends:
ii  libavcodec57  10:3.4.2-dmo3
ii  libavcodec58  10:4.1.3-dmo4

Versions of packages firefox-esr suggests:
pn  fonts-lmodern  
pn  fonts-stix | otf-stix  
pn  libcanberra0   
ii  libgssapi-krb5-2   1.17-10
ii  libgtk2.0-02.24.32-1
pn  pulseaudio 

-- no debconf information

Bug#983502: firefox-esr: depends on wrong libnss3 version, TLS hangs with 2:3.58-1

[Adam M. Costello]

Package: firefox-esr
Version: 78.7.0esr-1
Severity: important

Dear Maintainer,

firefox-esr (both the latest version 78.8.0esr-1 and the latest testing
version 78.7.0esr-1) depends on libnss3 (>= 2:3.53.1~), but that is not
sufficient. https fails completely with libnss3 2:3.58-1.  It works with
2:3.61-1 (the current testing version).  I didn't try any other versions
of libnss3.

Evidence:

When I updated firefox-esr from 78.3.0esr-2 to 78.7.0esr-1, https
stopped working.  The firefox developer console showed that it was
making the TCP connection but not getting past the TLS setup.  I tried
several versions of firefox-esr:

78.8.0esr-1 broken
78.7.0esr-1 broken
78.6.1esr-1 broken
78.5.0esr-1 worked
78.3.0esr-2 worked

Eventually I suspected libnss3, which was at version 2:3.58-1 this whole
time.  I updated it to 2:3.61-1 (the current testing version), then
retried firefox-esr 78.7.0esr-1 (the current testing version), and that
worked.

-- Package-specific info:


-- Addons package information

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (600, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.16.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages firefox-esr depends on:
ii  debianutils  4.8.6
ii  fontconfig   2.13.0-5
ii  libatk1.0-0  2.36.0-2
ii  libc62.30-8
ii  libcairo-gobject21.15.10-3
ii  libcairo21.15.10-3
ii  libdbus-1-3  1.12.8-2
ii  libdbus-glib-1-2 0.110-2
ii  libevent-2.1-7   2.1.11-stable-1
ii  libffi7  3.3-4
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.2+dfsg-2
ii  libgcc-s110-20200304-1
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.64.3-2
ii  libgtk-3-0   3.24.20-1
ii  libnspr4 2:4.29-1
ii  libnss3  2:3.61-1
ii  libpango-1.0-0   1.44.7-4
ii  libstdc++6   10-20200304-1
ii  libvpx6  1.8.0-dmo2
ii  libx11-6 2:1.7.0-2
ii  libx11-xcb1  2:1.7.0-2
ii  libxcb-shm0  1.13-1
ii  libxcb1  1.13.1-2
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.4-3
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxrender1  1:0.9.10-1
ii  procps   2:3.3.15-1
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages firefox-esr recommends:
ii  libavcodec57  10:3.4.2-dmo3
ii  libavcodec58  10:4.1.3-dmo4

Versions of packages firefox-esr suggests:
pn  fonts-lmodern  
pn  fonts-stix | otf-stix  
pn  libcanberra0   
ii  libgssapi-krb5-2   1.17-10
ii  libgtk2.0-02.24.32-1
pn  pulseaudio 

-- no debconf information

Bug#852532: Acknowledgement (olvwm: source code not 64-bit clean, SIGSEGV everywhere)

[Adam M. Costello]

I retract "SIGSEGV everywhere".  If I compile client.c with -O0, then
the third SIGSEGV is avoided, and I don't see any others.

Summary: olvwm runs on my system only if I make all three of these
changes, each of which avoids a SIGSEGV:

In cursors.c, remove (int) from this line:
st_insert(cursorTable, (int) p->name, (char *) p->num);

In image.c, #include "mem.h".

Compile client.c with -O0.

Alternatively, the first two SIGSEGVs (but not the third) can be avoided
by making no code changes but instead linking with -no-pie.

AMC

Bug#852532: olvwm: source code not 64-bit clean, SIGSEGV everywhere

[Adam M. Costello]

Package: olvwm
Version: 4.4.3.2p1.4-28.2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

The latest version (4.4.3.2p1.4-28.2) immediately crashes with SIGSEGV
on my x86_64 system.  I tried building it from source with debug
symbols, and discovered that it is not 64-bit clean (examples below).

The previous version (4.4.3.2p1.4-28.1), which was built 4 years ago,
works.  It can no longer be built (because glibc no longer supports some
old APIs), but I'm guessing that the build tools from 4 years ago must
have produced machine code where all the addresses fall in the bottom
4GB of the virtual address space, so that the 64-bit uncleanliness is
hidden.

I'm not sure what to do about this.  Fixing all the source code is
likely to be a large project.  Is there a way to tell today's build
tools to produce machine code confined to the bottom 4GB of the virtual
address space?

Example SIGSEGVs:

In clients/olvwm-4.1/cursors.c in InitCursors() there is a gratuitous
cast of a pointer to an int before it is passed to a function that takes
a pointer:

st_insert(cursorTable, (int) p->name, (char *) p->num);

After I fixed that, there was SIGSEGV in image.c in this line:

b = (Button *) MemAlloc(sizeof(Button));

The problem is that mem.h is not included, so the compiler assumes that
MemAlloc() returns an int rather than a pointer, so the pointer gets
truncated to 32 bits.

After I fixed that, there was a SIGSEGV in states.c in this line:

cli->wmState = initstate;

but gdb said cli was optimized out, so I don't know what's going on
there.  I suspect that these 64-bit issues are pervasive.

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (600, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.7.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages olvwm depends on:
ii  libc6 2.24-8
ii  libx11-6  2:1.6.4-2
ii  libxext6  2:1.3.3-1
ii  libxpm4   1:3.5.12-1

olvwm recommends no packages.

Versions of packages olvwm suggests:
pn  menu   
pn  olwm   
pn  xview-clients  

-- no debconf information

Bug#688814: pdfunite: error-prone command line arguments

[Adam M. Costello]

[Sorry for the duplicate, the first went to submit@ instead of 688814@.]

Eric Cooper  wrote:

> It is very easy to overwrite a desired input file when doing, i.e.,
> $ pdfunite page*.pdf
> instead of
> $ pdfunite page*.pdf new-file.pdf
>
> Using something like "-o output-file" would prevent this.

I just got bitten by this myself, using pdfunite 0.24.5 (from
poppler-utils 0.24.5-2ubuntu4.2).

This could be fixed in a backward-compatible way by supporting two
syntaxes:

# Explicit:
pdfunite -o outfile infile...

# Error if outfile already exists:
pdfunite infile... outfile

AMC

Bug#769719: nviboot fails to send recovery mail

[Adam M. Costello]

Package: nvi
Version: 1.81.6-11+b1
Severity: important
Tags: patch

Dear Maintainer,

/etc/init.d/nviboot attempts to send mail about recovery from crashed
editor sessions, but the attempt fails due to a misplaced quote.  This
line:

(su - nobody -s /bin/sh -c $SENDMAIL $owner  $i ) 
/dev/null /dev/null 20

should be:

(su - nobody -s /bin/sh -c $SENDMAIL $owner  $i ) 
/dev/null /dev/null 20

That is, the input redirection needs to be outside the quotes, so
that root opens the file, rather than inside the quotes, where it
causes nobody to open the file, which fails because the file is not
world-readable.

By the way, this kind of problem might be easier to detect if stderr
were not hidden.  I suspect that is done to hide the complaint from
su about the lack of home directory for user nobody.  Another way to
avoid that error is to omit the '-' from the su command.  So you might
consider changing that line to:

su nobody -s /bin/sh -c $SENDMAIL $owner  $i 

Also, do stdout and stderr from init scripts get logged anywhere?

History:

The need for quotes was reported against nvi_1.79-22 in bug 355639 on
2006-Mar-06.  The changelog claims that quotes were added in version
1.79-23 (2006-May-26):

   * Fix invocation of su in init.d/nvi to use quotes (closes: #355639)

But I looked at the 1.79-23 source, and there were still no quotes.

The need for quotes was then reported against nvi_1.79-25 in bug 465727
on 2008-Feb-14, which included a correct patch with the redirection
outside the quotes.  The changelog claims that the bug was fixed in
version 1.81.6-1 (2008-Jun-13):

   * Fix sendmail invocation in the initscript. Closes: #465727.

I looked at the source for the next version I could find, 1.81.6-3,
and found the erroneous syntax that survives to this day, with the
redirection inside the quotes.  I checked my mail archive, and I have
received no mail from nvi since 2008.  Of course it's still possible
to poll manually using 'vi -r'.  Maybe I should write a cron job to do
that...

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (600, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 3.14-1-686-pae (SMP w/1 CPU core)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages nvi depends on:
ii  libc6 2.18-7
ii  libdb5.3  5.3.28-3
ii  libncursesw5  5.9+20140118-1
ii  libtinfo5 5.9+20140118-1

Versions of packages nvi recommends:
pn  nvi-doc  none

nvi suggests no packages.

-- no debconf information


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

Bug#675748: dselect no longer shows package descriptions, /var/lib/dpkg/available no longer contains them

[Adam M. Costello]

In two years this bug seems to have gotten no attention from the apt 
maintainer.  Maybe it would help to change the bug description to
apt-cache dumpavail omits full description, unlike apt-cache show.

Thanks,
AMC


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

Bug#761459: libreadline6: terminfo delays not honored, visible bell nearly invisible

[Adam M. Costello]

Package: libreadline6
Version: 6.3-8
Severity: normal
Tags: upstream

Dear Maintainer,

When readline tries to flash my terminal (xterm), the flash is either
completely invisible or flashes only a fraction of the window (a
horizontal stripe) almost too fast to see.

My .inputrc has set bell-style visible.  I induce flashes by
pressing TAB in an interactive python shell or tclsh when there are no
completions.

My theory, based on reading the code and trying some experiments, is
that what's happening is this:

1. readline looks up the termcap flash string under vb and gets a
string containing a delay instruction: \E[?5h$100/\E[?5l

2. readline passes this string to tputs(), and passes a pointer to a
function that wraps putc().

3. tputs() calls that putc wrapper five times to output \E[?5h, then
sleeps for 0.1 seconds, then calls the wrapper five more times to output
\E[?5l .

4. But the output FILE stream is buffered, so none of those characters
have actually been sent to the terminal yet, until a later call to
fflush(), at which point all ten characters are sent at once.

A possible fix would be, when using tput() for the visible bell, to use
an alternate putc wrapper that calls fflush().  Or more generally, use
a tputs wrapper that inspects the string uses the putc-flush wrapper if
the string contains $.

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (600, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 3.13-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages libreadline6 depends on:
ii  libc6  2.18-4
ii  libtinfo5  5.9+20140712-2
ii  multiarch-support  2.18-4
ii  readline-common6.2+dfsg-0.1

libreadline6 recommends no packages.

libreadline6 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#732955: exiv2: creates new file in wrong place when old file is a relative symlink

[Adam M. Costello]

Package: exiv2
Version: 0.23-1
Severity: normal

Dear Maintainer,

exiv2 version 0.18.2 fixed a bug related to symlinks, but the fix
introduced two more bugs.

exiv2 is designed to give the illusion of modifying a file in place, but
actually it creates the new file, removes the old file, and renames the
new file to the old name.

The old bug (already fixed): If the file was a symlink, it would become
a plain file, and the file it used to point to would be truncated.

First new bug: If the file is a relative symlink, exiv2 interprets it
relative to the current working directory, rather than relative to the
symlink, when deciding where to create the new file.

Second new bug: If the file is a symlink to another symlink, exiv2
follows only the first.  If the first symlink is relative, the other bug
happens too, otherwise the second symlink gets replaced by a plain file.

The relative-symlink bug is very dangerous, because it can cause an
unrelated file to be removed.  For example, given these files:

foo.jpg
dir/foo.jpg
dir/bar.jpg -- foo.jpg

The command 'exiv2 options dir/foo.jpg' will unlink and replace
./foo.jpg, not dir/foo.jpg.

My workaround may provide a hint about how to fix this:

# Assume $@ contains all desired exiv2 options except the filename,
# which is in $file.
file=`readlink -e $file`
exiv2 $@ $file

-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (600, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages exiv2 depends on:
ii  libc62.13-38
ii  libexiv2-12  0.23-1
ii  libgcc1  1:4.7.2-5
ii  libstdc++6   4.7.2-5

exiv2 recommends no packages.

exiv2 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#694257: fdk-aac: who knows more?

[Adam M. Costello]

Fabian Greffrath fab...@greffrath.com:

 Is fdk-aac finally the first *free* high-quality AAC encoder or is it
 just the next *non-free* one after FAAC?

From what I've read, FAAC is not a high-quality AAC encoder.  As far as
I know, fdk-aac is the only high-quality open-source AAC encoder.

I don't know if fdk-aac is DFSG-free, or GPL-compatible, but even if
it's neither, Debian could still package it, right?  There's also a
command-line tool, fdkaac, that uses it.

Of course, the library would be much more useful if avconv could use it.
If libfdk-aac is GPL-incompatible, what does that imply?  That avconv
must not require libfdk-aac to be present at runtime?  Could it check
for the existence of libfdk-aac and dlopen() it if it's found?  Would
that make them independent enough that their licenses wouldn't need to
be compatible?

It's a shame that various open-source licenses fight each other and thus
impede rather than promote the development of free software.

AMC


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

Bug#676167: Acknowledgement (SEGV when libsox-fmt-oss is the only installed audio driver)

[Adam M. Costello]

This may be another clue:  I reinstalled libsox-fmt-alsa, and with
AUDIODRIVER unset, 'play foo.wav' issues a warning (before proceding to
play successfully):

play WARN alsa: can't encode 0-bit Unknown or not applicable

but 'play foo.wav -t alsa' issues no warning.

I'm guessing the absence of -t driver affects the order of
initialization, causing a warning for alsa and a SEGV for oss.

AMC



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

Bug#676167: SEGV when libsox-fmt-oss is the only installed audio driver

[Adam M. Costello]

Package: sox
Version: 14.4.0-3
Severity: normal

Dear Maintainer,

Rather than always pass '-t oss' to sox, or set AUDIODRIVER=oss, I
thought I'd just uninstall libsox-fmt-alsa and leave libsox-fmt-oss as
the only installed audio driver.  But this causes sox to SEGV:

$ play foo.wav
Segmentation fault

Curiously, using '-t oss' still works fine:

$ play foo.wav -t oss

foo.wav is little-endian 16-bit stereo 44100 Hz, created by cdparanoia.

Here are the results with -V9:

$ play -V9 foo.wav
play DBUG formats: opening format plugin `lsx_amr_nb_format_fn': library 
0x9df9490, entry point 0xb78352d0

play DBUG formats: opening format plugin `lsx_amr_wb_format_fn': library 
0x9dfa578, entry point 0xb756fe60

play DBUG formats: opening format plugin `lsx_flac_format_fn': library 
0x9dfaa80, entry point 0xb7831150

play DBUG formats: opening format plugin `lsx_gsm_format_fn': library 
0x9dfc988, entry point 0xb7423d00

play DBUG formats: opening format plugin `lsx_lpc10_format_fn': library 
0x9dfcda0, entry point 0xb782bd10

play DBUG formats: opening format plugin `lsx_oss_format_fn': library 
0x9dfd1b8, entry point 0xb741fdb0

play DBUG formats: opening format plugin `lsx_sndfile_format_fn': library 
0x9dfd5d0, entry point 0xb741c160

play DBUG formats: opening format plugin `lsx_vorbis_format_fn': library 
0x9dfde28, entry point 0xb7209c50

play DBUG formats: opening format plugin `lsx_wavpack_format_fn': library 
0x9dfe2e8, entry point 0xb72057d0

play INFO oss: OSS driver only supports bytes and words
play INFO oss: Forcing to signed linear word
Segmentation fault

$ play -V9 foo.wav -t oss
play:  SoX v14.4.0
time: May  7 2012 03:43:24
issue:Debian
uname:Linux luthien 3.0.0-1-686-pae #1 SMP Sat Aug 27 16:41:03 UTC 2011 i686
compiler: gcc 4.6.3
arch: 1248 48 44 L OMP
play DBUG formats: opening format plugin `lsx_amr_nb_format_fn': library 
0x9fc75d8, entry point 0xb77a92d0

play DBUG formats: opening format plugin `lsx_amr_wb_format_fn': library 
0x9fc86c0, entry point 0xb74e3e60

play DBUG formats: opening format plugin `lsx_flac_format_fn': library 
0x9fc8bc8, entry point 0xb77a5150

play DBUG formats: opening format plugin `lsx_gsm_format_fn': library 
0x9fcaad0, entry point 0xb7397d00

play DBUG formats: opening format plugin `lsx_lpc10_format_fn': library 
0x9fcaee8, entry point 0xb779fd10

play DBUG formats: opening format plugin `lsx_oss_format_fn': library 
0x9fcb300, entry point 0xb7393db0

play DBUG formats: opening format plugin `lsx_sndfile_format_fn': library 
0x9fcb718, entry point 0xb7390160

play DBUG formats: opening format plugin `lsx_vorbis_format_fn': library 
0x9fcbf70, entry point 0xb717dc50

play DBUG formats: opening format plugin `lsx_wavpack_format_fn': library 
0x9fcc430, entry point 0xb71797d0

play INFO formats: detected file format type `wav'
play DBUG wav: WAV Chunk fmt 
play DBUG wav: WAV Chunk data
play DBUG wav: Reading Wave file: Microsoft PCM format, 2 channels, 44100 
samp/sec
play DBUG wav: 176400 byte/sec, 4 block align, 16 bits/samp, 18987696 
data bytes
play DBUG wav: 4746924 Samps/chans

Input File : 'foo.wav'
Channels   : 2
Sample Rate: 44100
Precision  : 16-bit
Duration   : 00:01:47.64 = 4746924 samples = 8073 CDDA sectors
File Size  : 19.0M
Bit Rate   : 1.41M
Sample Encoding: 16-bit Signed Integer PCM
Endian Type: little
Reverse Nibbles: no
Reverse Bits   : no


Output File: '/dev/dsp' (ossdsp)
Channels   : 2
Sample Rate: 44100
Precision  : 16-bit
Duration   : 00:01:47.64 = 4746924 samples = 8073 CDDA sectors
Sample Encoding: 16-bit Signed Integer PCM
Endian Type: little
Reverse Nibbles: no
Reverse Bits   : no

play DBUG effects: sox_add_effect: extending effects table, new size = 8
play INFO sox: effects chain: input44100Hz  2 channels (multi) 16 bits 
00:01:47.64
play INFO sox: effects chain: output   44100Hz  2 channels (multi) 16 bits 
00:01:47.64
play DBUG sox: automatically entering interactive mode

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (600, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 3.0.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages sox depends on:
ii  libc62.13-21 
ii  libgomp1 4.6.1-4 
ii  libgsm1  1.0.13-3
ii  libltdl7 2.4.2-1 
ii  libmagic15.08-1  
ii  libpng12-0   1.2.46-3
ii  libsox-fmt-base  14.4.0-3
ii  libsox-fmt-oss   14.4.0-3
ii  libsox2  14.4.0-3
ii  zlib1g   1:1.2.3.4.dfsg-3

sox recommends no packages.

Versions of packages sox suggests:
pn  libsox-fmt-all  none

-- no debconf information



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

Bug#675748: dselect no longer shows package descriptions, /var/lib/dpkg/available no longer contains them

[Adam M. Costello]

[Sorry for the duplication, I forgot to reply-all.]

Guillem Jover guil...@debian.org wrote:

 I'm guessing you are not using the apt method? Perhaps the ftp one?

I am using the apt method.  I don't remember ever configuring the access
method in dselect, but I just now checked it, and it's apt.

 For now, one workaround that you could do, while not having to change
 your current dselect method could be to install apt, do an apt-update
 and use the program sync-available from dctrl-tools. This should give
 you back your Descriptions, but you'll need to rember to not update
 from dselect, only upgrade from it.

apt was already installed, but I installed it again to get the latest
version.  I then ran:

apt-get update
apt-get install dctrl-tools
sync-available

But ~32k of the ~42k packages in /var/lib/dpkg/available still have
Description-md5: instead of actual descriptions.

Any other ideas?  :)

 I'll look into fixing this for 1.16.4 or 1.16.5 for wheezy.

Thanks!
AMC



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

Bug#675748: dselect no longer shows package descriptions, /var/lib/dpkg/available no longer contains them

[Adam M. Costello]

Package: dselect
Version: 1.16.3
Severity: normal

Dear Maintainer,

dselect no longer shows package descriptions for the vast majority 
of packages, except for a one-line description.  Presumably this is
because the descriptions are absent from /var/lib/dpkg/available.  A
Description-md5 field has appeared in their place.

Being able to grep through /var/lib/dpkg/available was very convenient.
That's what I've always done whenever I would wonder if there was a 
Debian package that would help me solve any given problem.  Having the
full descriptions show up in dselect was also very useful.

Where have the descriptions gone?  How can I get them back into dselect
and back into a local text file I can search?

Thanks,
AMC

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (600, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 3.0.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages dselect depends on:
ii  dpkg  1.16.0.3 
ii  libc6 2.13-21  
ii  libgcc1   1:4.6.1-4
ii  libncursesw5  5.9-1
ii  libstdc++64.6.1-4  
ii  libtinfo5 5.9-7

dselect recommends no packages.

Versions of packages dselect suggests:
ii  perl  5.14.2-11

-- 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#657570: mutt: sender patterns (~e and %e) don't work in IMAP folder

[Adam M. Costello]

C. Meissa carsten.mei...@gmx.de wrote:

 Does
 
 set imap_headers=Sender
 
 fix your problem?

Yes!  Thanks!  Maybe Sender: should be added to the default set of
headers requested via IMAP.

AMC



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

Bug#657570: mutt: sender patterns (~e and %e) don't work in IMAP folder

[Adam M. Costello]

Package: mutt
Version: 1.5.20-9
Severity: normal


In a newly-opened IMAP folder, the patterns that look at the Sender:
header field (~e and %e) don't match any messages.  If I read a message
that should have matched, then the patterns will match that message (but
no others).  It looks like the Sender: header field is invisible to mutt
until I read the message.

To reproduce the bug:

Send a message containing a non-empty Sender: field to an account with
IMAP access (I used a Gmail account).

Open the inbox in mutt.

Searching for ~e . should match the test message, but will match
nothing.

Read the message.

Now the same search will match the test message.

-- Package-specific info:
Mutt 1.5.20 (2009-06-14)
Copyright (C) 1996-2009 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.

System: Linux 2.6.32-5-686 (i686)
ncurses: ncurses 5.7.20100313 (compiled with 5.7)
libidn: 1.15 (compiled with 1.18)
hcache backend: tokyocabinet 1.4.37
Compile options:
-DOMAIN
+DEBUG
-HOMESPOOL  +USE_SETGID  +USE_DOTLOCK  +DL_STANDALONE  +USE_FCNTL  -USE_FLOCK   
+USE_POP  +USE_IMAP  +USE_SMTP  
-USE_SSL_OPENSSL  +USE_SSL_GNUTLS  +USE_SASL  +USE_GSS  +HAVE_GETADDRINFO  
+HAVE_REGCOMP  -USE_GNU_REGEX  
+HAVE_COLOR  +HAVE_START_COLOR  +HAVE_TYPEAHEAD  +HAVE_BKGDSET  
+HAVE_CURS_SET  +HAVE_META  +HAVE_RESIZETERM  
+CRYPT_BACKEND_CLASSIC_PGP  +CRYPT_BACKEND_CLASSIC_SMIME  +CRYPT_BACKEND_GPGME  
-EXACT_ADDRESS  -SUN_ATTACHMENT  
+ENABLE_NLS  -LOCALES_HACK  +COMPRESSED  +HAVE_WC_FUNCS  +HAVE_LANGINFO_CODESET 
 +HAVE_LANGINFO_YESEXPR  
+HAVE_ICONV  -ICONV_NONTRANS  +HAVE_LIBIDN  +HAVE_GETSID  +USE_HCACHE  
-ISPELL
SENDMAIL=/usr/sbin/sendmail
MAILPATH=/var/mail
PKGDATADIR=/usr/share/mutt
SYSCONFDIR=/etc
EXECSHELL=/bin/sh
MIXMASTER=mixmaster
To contact the developers, please mail to mutt-...@mutt.org.
To report a bug, please visit http://bugs.mutt.org/.

misc/am-maintainer-mode
misc/hg.pmdef.debugtime
debian-specific/build_doc_adjustments.diff
features/ifdef
features/xtitles
features/trash-folder
features/purge-message
features/sensible_browser_position
features-old/patch-1.5.4.vk.pgp_verbose_mime
features/compressed-folders
features/compressed-folders.debian
debian-specific/Muttrc
debian-specific/Md.etc_mailname_gethostbyname.diff
debian-specific/use_usr_bin_editor.diff
debian-specific/correct_docdir_in_man_page.diff
debian-specific/dont_document_not_present_features.diff
debian-specific/document_debian_defaults
debian-specific/assumed_charset-compat
debian-specific/467432-write_bcc.patch
misc/define-pgp_getkeys_command.diff
misc/gpg.rc-paths
misc/smime.rc
upstream/533209-mutt_perror.patch
upstream/533459-unmailboxes.patch
upstream/533439-mbox-time.patch
upstream/531430-imapuser.patch
upstream/534543-imap-port.patch
upstream/538128-mh-folder-access.patch
upstream/537818-emptycharset.patch
upstream/535096-pop-port.patch
upstream/542910-search-segfault.patch
upstream/533370-pgp-inline.patch
upstream/533520-signature-highlight.patch
upstream/393926-internal-viewer.patch
upstream/543467-thread-segfault.patch
upstream/544180-italian-yesorno.patch
upstream/542817-smimekeys-tmpdir.patch
upstream/544794-smtp-batch.patch
upstream/537694-segv-imap-headers.patch
upstream/548577-gpgme-1.2.patch
upstream/548494-swedish-intl.patch
upstream/553321-ansi-escape-segfault.patch
upstream/553238-german-intl.patch
upstream/557395-muttrc-crypto.patch
upstream/545316-header-color.patch
upstream/568295-references.patch
upstream/547980-smime_keys-chaining.patch
upstream/528233-readonly-open.patch
upstream/228671-pipe-mime.patch
upstream/383769-score-match.patch
upstream/547739-manual-typos.patch
upstream/311296-rand-mktemp.patch
upstream/573823-imap_internal_date
upstream/542344-dont_fold_From_
upstream/path_max
misc/hyphen-as-minus.patch
misc/smime_keys-manpage.patch
mutt.org

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (600, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages mutt depends on:
ii  libc6 2.11.2-5   Embedded GNU C Library: Shared lib
ii  libcomerr21.41.12-2  common error description library
ii  libgnutls26   2.8.6-1the GNU TLS library - runtime libr
ii  libgpg-error0 1.6-1  library for common error values an
ii  libgpgme111.2.0-1.2  GPGME - GnuPG Made Easy
ii  libgssapi-krb5-2  1.8.3+dfsg~beta1-1 MIT Kerberos runtime libraries - k
ii  libidn11  1.15-2 GNU Libidn library, implementation
ii  libk5crypto3  1.8.3+dfsg~beta1-1 MIT Kerberos runtime libraries - C
ii  libkrb5-3 1.8.3+dfsg~beta1-1 MIT Kerberos runtime 

Bug#644038: olvwm corrupts DISPLAY when running menu commands if DISPLAY has screen number

[Adam M. Costello]

Package: olvwm
Version: 4.4.3.2p1.4-28
Severity: important
Tags: patch

Dear Maintainer,

In bug 635154 I reported the exact opposite bug: olvwm corrupts DISPLAY
when running menu commands if DISPLAY *lacks* screen number.  Someone
else reported the same problem in bug 617236 and provided a misguided
patch that was unfortunately applied (debian/patches/display_setting).

This has merely altered the bug so that the corruption occurs in
different circumstances (when DISPLAY *has* a screen number).

The patch changed %.*s to %*s, which causes the variable 'len' to
be interpreted as a field width (affecting how many spaces are inserted
into the output) rather than a precision (controlling how big a prefix
of the original DISPLAY to copy), which is nonsense.  That dot needs to
be restored.

The original sprintf line made sense.  It appends the specified screen
number to a prefix of the original DISPLAY.  The prefix is intended to
be everything except the screen number.  The prefix length is calculated
correctly when the original DISPLAY has a screen number (contains a
dot), but incorrectly when the original DISPLAY lacks a screen number
(lacks a dot).  The fix is therefore to correct that calculation:

-   len = colon - display;
+   len = strlen(display);

Disclaimer:  I haven't tested that.  I'm not set up to build Debian
packages from source.

Thanks,
AMC

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (600, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 3.0.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages olvwm depends on:
ii  libc6 2.13-21  
ii  libx11-6  2:1.4.4-1
ii  libxext6  2:1.3.0-3
ii  libxpm4   1:3.5.9-1

olvwm recommends no packages.

Versions of packages olvwm suggests:
pn  menu   2.1.45
pn  olwm   none
pn  xview-clients  none

-- 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#635679: useradd and groupadd fail if /etc/passwd and /etc/group are symlinks

[Adam M. Costello]

Nicolas François nicolas.franc...@centraliens.net wrote:

 How did shadow behave before this change?
 
 I think that it could read successfully the files, but then it probably
 destroyed the links every time a change was committed.

I don't remember.

 I would expect the same behavior from PAM when passwords are changed.

Indeed, I just now tried changing my password, and it destroyed the
links.

AMC



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

Bug#635679: useradd and groupadd fail if /etc/passwd and /etc/group are symlinks

[Adam M. Costello]

Package: passwd
Version: 1:4.1.4.2+svn3283-3
Severity: normal

Until revision 3095 in the upstream svn, useradd and groupadd worked
just fine if /etc/passwd and /etc/group were symlinks.  That revision
added the O_NOFOLLOW flag to open() in lib/commonio.c, and now those
tools fail to open /etc/passwd and /etc/group if they are symlinks.  I
don't use those tools myself, but Debian package installation scripts
seem to use them.  Can we go back to allowing symlinks?  My system
for managing my three Debian installations is based on keeping all my
customizations in a separate directory, with symlinks from /etc/.

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (600, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages passwd depends on:
ii  debianutils   4.0.2  Miscellaneous utilities specific t
ii  libc6 2.13-10Embedded GNU C Library: Shared lib
ii  libpam-modules1.1.3-2Pluggable Authentication Modules f
ii  libpam0g  1.1.3-2Pluggable Authentication Modules l
ii  libselinux1   2.0.98-1.1 SELinux runtime shared libraries

passwd recommends no packages.

passwd suggests no packages.

-- debconf information:
  passwd/password-mismatch:
  passwd/username: local-amc
  passwd/password-empty:
  passwd/make-user: true
  passwd/title:
  passwd/user-uid:
  passwd/shadow: true
  passwd/username-bad:
  passwd/user-fullname:



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

Bug#635154: olvwm corrupts DISPLAY when running menu commands if DISPLAY lacks screen number

[Adam M. Costello]

Package: olvwm
Version: 4.4.3.2p1.4-25
Severity: important

If DISPLAY lacks a screen number (for example, :0 rather than :0.0) then
olvwm corrupts it when running a command from the popup menu, preventing
the command from connecting to the X server.

For example, with DISPLAY=:0 olvwm will invoke menu commands with
DISPLAY=.0 which is invalid.  You can reproduce this by adding a menu
command in ~/.openwin-menu that invokes a script that writes $DISPLAY to
some file.

A workaround is to rewrite DISPLAY in ~/.xsession to append .0 if
DISPLAY lacks a screen number.

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (600, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.39-2-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages olvwm depends on:
ii  libc6 2.13-10Embedded GNU C Library: Shared lib
ii  libx11-6  2:1.4.3-2  X11 client-side library
ii  libxext6  2:1.3.0-3  X11 miscellaneous extension librar
ii  libxpm4   1:3.5.9-1  X11 pixmap library

olvwm recommends no packages.

Versions of packages olvwm suggests:
ii  menu  2.1.45 generates programs menu for all me
pn  olwm  none (no description available)
pn  xview-clients none (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#611964: netcat-openbsd: -q -1 does not behave as the man page says

[Adam M. Costello]

Package: netcat-openbsd
Version: 1.89-4
Severity: normal


The man page says a negative value for -q means infinity.  But the code
makes no distinction between negative and zero.  The bug was introduced
in 1.89-4, and is related to bug #502188.

In version 1.89-3, -q behaved as documented (negative was treated as
infinite), and the default was -1.  As described in the changelog,
1.89-4 decided that the default behavior should be like -q 0.  A
one-line patch was offered to change the default from -1 to 0:

http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=10;filename=fix-quit-timer-patch.patch;att=1;bug=502188

But that patch was not used.  Instead, the default value was left as -1,
and the code was changed to treat negative values the same as 0.  So now
-q -1 is no different from -q 0.  If you want an infinite quit timer,
you need to do something like -q 9, although the man page still
says -q -1 should work.

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (600, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages netcat-openbsd depends on:
ii  libc6 2.11.2-5   Embedded GNU C Library: Shared lib
ii  libglib2.0-0  2.24.1-1   The GLib library of C routines

netcat-openbsd recommends no packages.

netcat-openbsd suggests no packages.

-- no debconf information



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

Bug#599778: tgif depends on gettext?

[Adam M. Costello]

Package: tgif
Version: 1:4.1.45-3
Severity: normal


Does tgif really need to depend on gettext, or would gettext-base be
sufficient? gettext pulls in git.

AMC

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (600, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages tgif depends on:
ii  debconf [debconf-2.0] 1.5.35 Debian configuration management sy
ii  gettext   0.18.1.1-1 GNU Internationalization utilities
ii  libc6 2.11.2-2   Embedded GNU C Library: Shared lib
ii  libice6   2:1.0.6-1  X11 Inter-Client Exchange library
ii  libsm62:1.1.1-1  X11 Session Management library
ii  libx11-6  2:1.3.3-3  X11 client-side library
ii  libxext6  2:1.1.2-1  X11 miscellaneous extension librar
ii  libxt61:1.0.7-1  X11 toolkit intrinsics library

tgif recommends no packages.

tgif suggests no packages.

-- Configuration Files:
/etc/X11/app-defaults/Tgif changed [not included]
/etc/X11/ja_JP.eucJP/app-defaults/Tgif changed [not included]
/etc/X11/ru/app-defaults/Tgif changed [not included]

-- debconf information excluded



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

Bug#574658: dpkg: [CONFFILE] purging conffile replaced by symlink removes target, not symlink

[Adam M. Costello]

I just noticed this behavior too, and I find it astonishing and
worrisome.  I sometimes manually replace a conf file with a symlink
to a file in my own private config directory (example: /etc/foo -
/mydir/foo).  I always assumed that dpkg remove --purge would remove
the conf file /etc/foo and not touch /mydir/foo, but in fact just the
opposite happens: it removes /mydir/foo and leaves the dangling symlink
/etc/foo. /mydir is mine, not part of any package, so the package system
should not be touching it.

Was there some motivation for this behavior?  It's caused by a call to
conffderef() in remove.c, but what for?

AMC



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

Bug#577845: dvi2ps: SIGSEGV every time

[Adam M. Costello]

Package: dvi2ps
Version: 4.1j-3
Severity: important

Whenever I run dvi2ps, it immediately crashes, producing this output:

---quote---
@(#)dvi2ps (j-version) 4.1j

Prescanning Segmentation fault
---unquote---

and a log message like:

kernel: [8971046.561510] dvi2ps[12166]: segfault at 21 ip b7dc31bb sp bffda46c 
error 4 in libc-2.9.so[b7d4c000+15a000]

where some of those fields vary; the invariant parts are:

kernel: [..] dvi2ps[.]: segfault at 21 ip b7dc31bb sp  
error 4 in libc-2.9.so[+15a000]

This happens even for trivial input, for example, with foo.tex containing:

\documentclass{article}
\begin{document}
hello, world
\end{document}

I then produce foo.dvi with either 'latex foo' (from texlive-latex-base)
or 'jlatex foo' (from jtex-bin).  Either way, 'dvi2ps foo' crashes.

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (600, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-2-686 (SMP w/1 CPU core)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages dvi2ps depends on:
ii  debconf [debconf-2.0]1.5.27  Debian configuration management sy
ii  libc62.9-12  GNU C Library: Shared libraries
ii  libfreetype6 2.3.9-4.1   FreeType 2 font engine, shared lib
ii  libkpathsea5 2009-5  TeX Live: path search library for 
ii  texlive-base-bin 2007.dfsg.2-6   TeX Live: Essential binaries
ii  vflib3   3.6.14.dfsg-1.1 Versatile Font Library

dvi2ps recommends no packages.

Versions of packages dvi2ps suggests:
ii  dvi2ps-fontdata-ja1.0.1-3Font data for dvi2ps-j and dvi2dvi

-- debconf information:
  dvi2ps/fontdesc:
  dvi2ps/configk:



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

Bug#571779: closed by OHURA Makoto oh...@debian.org (Bug#571779: fixed in dvi2ps 4.1j-3)

[Adam M. Costello]

 Source: dvi2ps
 Source-Version: 4.1j-3
 
 We believe that the bug you reported is fixed in the latest version of
 dvi2ps,

I installed that version, and now instead of getting an error message
(dvi2ps: FATAL-- cannot open fontdesc file bikan-mor2) I get a
SIGSEGV:

kernel: [8930844.284122] dvi2ps[8008]: segfault at 21 ip b7ceb1bb sp
bfa0324c error 4 in libc-2.9.so[b7c74000+15a000]

That's with the trivial input I described earlier:

\documentclass{article}
\begin{document}
hello, world
\end{document}

It happens regardless of whether I use jlatex or latex.

AMC



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

Bug#571779: dvi2ps: FATAL-- cannot open fontdesc file bikan-mor2

[Adam M. Costello]

Package: dvi2ps
Version: 4.1j-2
Severity: grave
Justification: renders package unusable

Whenever I run 'dvi2ps foo' I get the following error message (and
nothing else):

dvi2ps: FATAL-- cannot open fontdesc file bikan-mor2

This used to work.  It happens even for a trivial foo.tex:

\documentclass{article}
\begin{document}
hello, world
\end{document}

I then produce foo.dvi with either 'latex foo' (from texlive-latex-base)
or 'jlatex foo' (from jtex-bin).  Either way, dvi2ps fails, complaining
about bikan-mor2.

dvi2ps worked for me for many years, but I hadn't tried it in the last
few years, so some upgrade in the last few years must have broken it.

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (600, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-2-686 (SMP w/1 CPU core)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages dvi2ps depends on:
ii  debconf [debconf-2.0]1.5.27  Debian configuration management sy
ii  libc62.9-12  GNU C Library: Shared libraries
ii  libfreetype6 2.3.9-4.1   FreeType 2 font engine, shared lib
ii  libkpathsea4 2007.dfsg.2-6   TeX Live: path search library for 
ii  texlive-base-bin 2007.dfsg.2-6   TeX Live: Essential binaries
ii  vflib3   3.6.14.dfsg-1.1 Versatile Font Library

dvi2ps recommends no packages.

Versions of packages dvi2ps suggests:
ii  dvi2ps-fontdata-ja1.0.1-2Font data for dvi2ps-j and dvi2dvi

-- debconf information:
  dvi2ps/fontdesc:
  dvi2ps/configk:



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

Bug#566639: dash: wait $pid exits before $pid has terminated

[Adam M. Costello]

Package: dash
Version: 0.5.5.1-3
Severity: normal

I've discovered a situation in which wait $pid exits before process
$pid has terminated.  Maybe EINTR is not being handled when calling
wait()?  Here's a script to reproduce it:

#!/bin/sh
#
# This script illustrates an anomaly when trapping SIGTSTP and waiting
# for a child to exit.  When the suspend key is pressed, the background
# process is stopped (to see this run ps -lp pid in another window).
# Then, when the TSTP handler finishes (after you press the Enter key),
# the background process is continued (why?) and the wait command exits
# (why?).  This happens in both bash and dash, but I don't see anything
# in the POSIX spec to support this behavior.  I expect the background
# process to remain stopped.  Regardless of whether the background
# process stays stopped or continues, I expect the wait command to keep
# waiting until the background process terminates.
#
trap 'read junk' TSTP
sleep 60 
pid=$!
echo background process ID: $pid
wait $pid
echo wait exited with status=$?

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (600, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-2-686 (SMP w/1 CPU core)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages dash depends on:
ii  debianutils   3.2Miscellaneous utilities specific t
ii  dpkg  1.15.3.1   Debian package management system
ii  libc6 2.9-12 GNU C Library: Shared libraries

dash recommends no packages.

dash suggests no packages.

-- debconf information:
  dash/sh: false



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

Bug#566641: bash: wait $pid exits before $pid has terminated

[Adam M. Costello]

Package: bash
Version: 4.1-1
Severity: normal

I've discovered a situation in which wait $pid exits before process
$pid has terminated.  Here's a script to reproduce it:

#!/bin/sh
#
# This script illustrates an anomaly when trapping SIGTSTP and waiting
# for a child to exit.  When the suspend key is pressed, the background
# process is stopped (to see this run ps -lp pid in another window).
# Then, when the TSTP handler finishes (after you press the Enter key),
# the background process is continued (why?) and the wait command exits
# (why?).  This happens in both bash and dash, but I don't see anything
# in the POSIX spec to support this behavior.  I expect the background
# process to remain stopped.  Regardless of whether the background
# process stays stopped or continues, I expect the wait command to keep
# waiting until the background process terminates.
#
trap 'read junk' TSTP
sleep 60 
pid=$!
echo background process ID: $pid
wait $pid
echo wait exited with status=$?

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (600, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-2-686 (SMP w/1 CPU core)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages bash depends on:
ii  base-files5.0.0  Debian base system miscellaneous f
ii  dash  0.5.5.1-3  POSIX-compliant shell
ii  debianutils   3.2Miscellaneous utilities specific t
ii  libc6 2.9-12 GNU C Library: Shared libraries
ii  libncurses5   5.7+20090803-2 shared libraries for terminal hand

Versions of packages bash recommends:
ii  bash-completion   1:1.0-3programmable completion for the ba

Versions of packages bash suggests:
pn  bash-doc  none (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#545757: gphoto2: in shell mode ls and tab-completion use different sorting

[Adam M. Costello]

Package: gphoto2
Version: 2.4.5-2
Severity: normal


In shell mode, tab-completion lists files in the usual column-major order:

1 4 7
2 5 8
3 6 9

but ls lists files in row-major order (unlike the unix ls command):

1 2 3
4 5 6
7 8 9

ghoto2's ls should be consistent with its tab-completion and with unix
ls.

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (600, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-2-686 (SMP w/1 CPU core)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages gphoto2 depends on:
ii  libaa11.4p5-38   ascii art library
ii  libc6 2.9-12 GNU C Library: Shared libraries
ii  libcdk5   5.0.20060507-1 C-based curses widget library
ii  libexif12 0.6.17-1   library to parse EXIF files
ii  libgphoto2-2  2.4.6-1gphoto2 digital camera library
ii  libgphoto2-port0  2.4.6-1gphoto2 digital camera port librar
ii  libjpeg62 6b-14  The Independent JPEG Group's JPEG 
ii  libncurses5   5.7+20090523-1 shared libraries for terminal hand
ii  libpopt0  1.14-4 lib for parsing cmdline parameters
ii  libreadline5  5.2-4  GNU readline and history libraries

gphoto2 recommends no packages.

Versions of packages gphoto2 suggests:
pn  gthumbnone (no description available)
pn  gtkam none (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#526818: netcat-openbsd: please push -q flag upstream

[Adam M. Costello]

Package: netcat-openbsd
Version: 1.89-3
Severity: wishlist

This request applies equally to netcat-openbsd and netcat-traditional.

I find the -q flag to be very useful.  It's been a Debian-specific
extension for years.  Please encourage the upstream maintainers to
incorporate it.

Thanks,
AMC

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (600, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-2-686 (SMP w/1 CPU core)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages netcat-openbsd depends on:
ii  libc6 2.9-4  GNU C Library: Shared libraries
ii  libglib2.0-0  2.20.0-2   The GLib library of C routines

netcat-openbsd recommends no packages.

netcat-openbsd suggests no packages.

-- no debconf information



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

Bug#524796: madwifi-tools: /etc/modprobe.d/madwifi needs to end with .conf

[Adam M. Costello]

Package: madwifi-tools
Version: 1:0.9.4+r3685.20080531+dfsg-1
Severity: normal

The configuration file /etc/modprobe.d/madwifi needs to be renamed to
end with .conf. module-init-tools is issuing warnings at boot time
that a future release will ignore files that don't end with .conf.

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (600, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-2-686 (SMP w/1 CPU core)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages madwifi-tools depends on:
ii  libc6 2.9-4  GNU C Library: Shared libraries

madwifi-tools recommends no packages.

madwifi-tools 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#513871: uswsusp: s2both does not resume after battery runs out

[Adam M. Costello]

Package: uswsusp
Version: 0.7-1.2
Severity: normal

s2both (invoked via pm-suspend-hybrid) saves a disk image and then
puts my ThinkPad T41p to sleep.  I can then wake the laptop and it
correctly resumes from RAM.  Or from the sleep state I can power it
off (by holding down the power button), then power it back on, and it
correctly resumes from disk.

But if the battery runs out while it's sleeping, the next time I power
it on, it does not resume, it just does a normal boot.

Has anyone else experienced this?

I think I once heard a beep come from my laptop when it was supposedly
sleeping, and the next time I looked at it (maybe an hour later) the
battery had run out, which makes me wonder if while it's asleep it
detects the battery running low and counter-productively wakes itself
up.

AMC

-- System Information:
Debian Release: 5.0
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (600, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages uswsusp depends on:
ii  debconf [debconf-2.0] 1.5.24 Debian configuration management sy
ii  libc6 2.7-16 GNU C Library: Shared libraries
ii  libgcc1   1:4.3.2-1  GCC support library
ii  libgcrypt11   1.4.1-1LGPL Crypto library - runtime libr
ii  liblzo2-2 2.03-1 data compression library
ii  libpci3   1:3.0.0-6  Linux PCI Utilities (shared librar
ii  libsplashy1   0.3.10-2.1 Library to draw splash screen on b
ii  libx86-1  1.1+ds1-2  x86 real-mode library

Versions of packages uswsusp recommends:
ii  initramfs-tools   0.92m  tools for generating an initramfs
ii  mount 2.13.1.1-1 Tools for mounting and manipulatin

Versions of packages uswsusp suggests:
pn  splashy   none (no description available)

-- debconf information:
  uswsusp/compute_checksum: false
  uswsusp/no_snapshot:
  uswsusp/suspend_loglevel:
  uswsusp/no_swap:
  uswsusp/resume_offset:
  uswsusp/early_writeout: true
  uswsusp/image_size: 427133419
  uswsusp/compress: true
  uswsusp/create_RSA_key: false
  uswsusp/snapshot_device:
  uswsusp/RSA_key_file: /etc/uswsusp.key
  uswsusp/max_loglevel:
  uswsusp/resume_device: /dev/hda6
  uswsusp/shutdown_method: platform
  uswsusp/encrypt: false
  uswsusp/splash: false
  uswsusp/RSA_key_bits: 1024
* uswsusp/continue_without_swap: true



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

Bug#509018: Upstream bug

[Adam M. Costello]

Mehdi Tibouchi mehdi.tibou...@normalesup.org wrote:

 This seems to be the same bug as [#FP-1008] and [#FP-1017] on Adobe's
 bug tracker:
 
 http://bugs.adobe.com/jira/browse/FP-1008
 http://bugs.adobe.com/jira/browse/FP-1017

Maybe, or maybe it's the same as Debian bug 509235.

People who are experiencing this bug (509018), try installing
libcurl3-gnutls and see if that fixes it.  It appears that
flashplugin-nonfree might actually depend on that library although it
doesn't say it does.

AMC



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

Bug#509235: iceweasel crashes when libcurl3-gnutls is not installed

[Adam M. Costello]

Mike Hommey m...@glandium.org wrote:

 That's not iceweasel requiring curl-gnutls, but something else you
 installed.

I have just experienced the same problem and same workaround.  I suspect
that the Flash plugin is the culprit.  I grep'ed for curl-gnutls in all
my extensions and plugins, and Flash was the only one that matched.
flashplugin-nonfree 1:2.2.

AMC



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

Bug#508107: sox: trim effect on WAV input loses 44 bytes at the end

[Adam M. Costello]

Package: sox
Version: 14.0.1-2+b1
Severity: normal

sox foo.wav bar.wav trim start

correctly trims the start, but erroneously trims 44 bytes from the end
as well.  It's probably no coincidence that the WAV header is 44 bytes.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (600, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.21-2-686 (SMP w/1 CPU core)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages sox depends on:
ii  libc6 2.7-15 GNU C Library: Shared libraries
ii  libltdl3  1.5.26-4   A system independent dlopen wrappe
ii  libsamplerate00.1.4-1audio rate conversion library
ii  libsox0   14.0.1-2+b1 SoX library

Versions of packages sox recommends:
pn  libsox-fmt-alsa | libsox-fmt- none (no description available)
pn  libsox-fmt-base   none (no description available)

-- no debconf information



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

Bug#504955: acpi-support: suspendorhibernate method 'dbus-pm' exits without doing anything

[Adam M. Costello]

Package: acpi-support
Version: 0.109-6
Severity: normal

The logic for method 'dbus-pm' in
/usr/share/acpi-support/suspendorhibernate looks a little screwy.  It
runs the command

/usr/bin/dbus-send \
  --session \
  --dest=org.freedesktop.PowerManagement \
  --type=method_call \
  --print-reply \
  --reply-timeout=2000 \
  /org/freedesktop/PowerManagement \
  org.freedesktop.PowerManagement.Suspend

as root, which on my system results in the following error:

Failed to open connection to session message bus: Did not receive
a reply. Possible causes include: the remote application did not
send a reply, the message bus security policy blocked the reply, the
reply timeout expired, or the network connection was broken.

But apparently that's not the error message it was expecting; it's
grepping for  org.freedesktop.DBus.Error. (which is the error produced
when the command is run as myself rather than root).  It erroneously
takes this branch:

# Not a DBUS error: other side does exist, and
# reports an error. That means we don't try
# anything else.
exit

The way I read the error message, there is no other side, and
suspendorhibernate should try the next method.

For now I've worked around the problem by removing dbus-pm from
SUSPEND_METHODS in /etc/default/acpi-support.

AMC

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (600, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.21-2-686 (SMP w/1 CPU core)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages acpi-support depends on:
pn  acpi-support-base none (no description available)
pn  acpid none (no description available)
ii  dmidecode 2.9-1  Dump Desktop Management Interface 
ii  finger0.17-11user information lookup program
ii  hdparm7.7-1  tune hard disk parameters for high
ii  laptop-detect 0.12.1-0.1 attempt to detect a laptop
ii  libc6 2.7-5  GNU C Library: Shared libraries
ii  lsb-base  3.1-24 Linux Standard Base 3.1 init scrip
pn  nvclock   none (no description available)
pn  powermgmt-basenone (no description available)
pn  radeontoolnone (no description available)
pn  toshset   none (no description available)
ii  vbetool   1.0-1.1run real-mode video BIOS code to a
pn  x11-xserver-utils none (no description available)

acpi-support recommends no packages.



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

Bug#494611: iceweasel: 3.0 crashes when tab containing embedded mplayer is closed

[Adam M. Costello]

Package: iceweasel
Version: 3.0.1-1
Severity: normal

When a tab or window containing an embedded video being handled by
mozilla-mplayer (mplayerplug-in) is closed, firefox crashes.  I'm using
mozilla-mplayer 1:3.55-0.0 and mplayer 1:1.0.rc2svn20080531-0.1 from
debian-multimedia.org.  I tried downgrading mozilla-mplayer to the
stable version (3.40) but that made no difference.  I've observed the
problem with iceweasel 3.0 rc2 and 3.0.1.  The plug-in worked fine with
iceweasel 2.x.  It doesn't seem to matter how the video is embedded
(I've tried both object and iframe), but there is no problem if the
mplayer occupies the whole window (the location bar contains the URL of
the video).

I tried to get a backtrace but was unable.  Here's a transcript of my
attempt (which contains an error message, but no stack trace):

# MOZ_DISABLE_PANGO=1 iceweasel -g -P clean -safe-mode --sync
(gdb) set pagination off 
(gdb) run
...
ctrl-C
(gdb) break gdk_x_error
Function gdk_x_error not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (gdk_x_error) pending.
(gdb) cont
Continuing
...
The program 'firefox-bin' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
  (Details: serial 64204 error_code 3 request_code 10 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

Program exited with code 01.
(gdb) bt full
No stack.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (600, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.25-2-686 (SMP w/1 CPU core)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages iceweasel depends on:
ii  debianutils   2.28.4 Miscellaneous utilities specific t
ii  fontconfig2.6.0-1generic font configuration library
ii  libc6 2.7-10 GNU C Library: Shared libraries
ii  libgcc1   1:4.3.1-2  GCC support library
ii  libglib2.0-0  2.16.3-2   The GLib library of C routines
ii  libgtk2.0-0   2.12.10-2  The GTK+ graphical user interface 
ii  libnspr4-0d   4.7.1-3NetScape Portable Runtime Library
ii  libstdc++64.3.1-2The GNU Standard C++ Library v3
ii  procps1:3.2.7-8  /proc file system utilities
ii  psmisc22.6-1 Utilities that use the proc filesy
ii  xulrunner-1.9 1.9.0.1-1  XUL + XPCOM application runner

iceweasel recommends no packages.

-- no debconf information



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

Bug#488844: iceweasel: Does not print

[Adam M. Costello]

iceweasel 2.0 was able to print just fine, but iceweasel 3.0 only offers
me the option of printing to a file (which I can then print using lp).
Here is the printer entry from /etc/printcap:

lp|angrist (HP Color LaserJet 3800dn):\
  :lp=:\
  :rm=angrist:\
  :sd=/var/spool/lpd/angrist:\
  :mx#0:\
  :sh:

AMC



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

Bug#436267: stuck at 2.6.21

[Adam M. Costello]

I'm just a regular Debian user who long ago built my own kernels (for
a forgotten reason) and ran into headaches getting out of sync with
the official config, so for the past several years I've been using the
pre-built Debian kernel images, and generally been happier.

But now I have a DV video camera and the only way I know to get the data
off the tapes is with dvgrab, which works on 2.6.21 and not on any later
Debian kernel image (so far).

I normally track the testing release, but now I'm stuck at 2.6.21 until
a later release works with dvgrab.

AMC



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

Bug#442946: *.debian.pool.ntp.org do not exist on 4 of 5 pool.ntp.org name servers

[Adam M. Costello]

Package: ntp
Version: 1:4.2.4p3+dfsg-1
Severity: grave
Justification: renders package unusable

Of the five name servers for pool.ntp.org, four of them claim there is no
such host as 1.debian.pool.ntp.org, etc.  To investigate this:

dig -t ns pool.ntp.org
# Shows the name servers to be [a-e].ntpns.org.
dig @a.ntpns.org 1.debian.pool.ntp.org
dig @b.ntpns.org 1.debian.pool.ntp.org
dig @c.ntpns.org 1.debian.pool.ntp.org
dig @d.ntpns.org 1.debian.pool.ntp.org
dig @e.ntpns.org 1.debian.pool.ntp.org

I find that only b.ntpns.org knows of 1.debian.pool.ntp.org (and the
other digits).  I've observed that 1.debian.pool.ntp.org resolves
on some systems and not on others, which is what you'd expect from
inconsistent authoritative servers.

This problem can be worked around by reverting the config to use
pool.ntp.org.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (600, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.21-2-686 (SMP w/1 CPU core)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages ntp depends on:
ii  adduser   3.105  add and remove users and groups
ii  libc6 2.6.1-1+b1 GNU C Library: Shared libraries
ii  libcap1   1:1.10-14  support for getting/setting POSIX.
ii  libreadline5  5.2-3  GNU readline and history libraries
ii  libssl0.9.8   0.9.8e-6   SSL shared libraries
ii  lsb-base  3.1-24 Linux Standard Base 3.1 init scrip
ii  netbase   4.30   Basic TCP/IP networking system
ii  perl  5.8.8-7Larry Wall's Practical Extraction 

ntp recommends no packages.

-- no debconf information



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

Bug#426464: libgphoto2-2: cannot get movie thumbnails on Canon SD700

[Adam M. Costello]

Package: libgphoto2-2
Version: 2.3.1-3
Severity: normal

With version 2.2.1-16 (the stable version) I can get thumbnails for both
still images and movies from my Canon PowerShot SD700 IS.  With version
2.3.1-3 (the testing version), I can still get the thumbnails for the
still images, but for the movies I get an error:

Downloading 'MVI_2669.AVI' from folder '/store_00010001/DCIM/100CANON'...  
Downloading 'MVI_2669.AVI' from folder '/store_00010001/DCIM/100CANON'...
*** Error (-6: 'Unsupported operation') ***   

Another difference is that the stable version blanks the display on the
camera (to save battery power), but the testing version does not.

With either version, if I remove my .gphoto/ directory, it gets
recreated with a settings file containing:

gphoto2=model=Canon Digital IXUS 800 (PTP mode)
gphoto2=port=usb:

which is correct, because the PowerShot SD700 IS and the Digital IXUS
800 are the same model in different markets.

-- System Information:
Debian Release: 4.0
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (700, 'oldstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-686
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)


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

Bug#393454: my .gv stopped working

[Adam M. Costello]

Package: gv
Version: 1:3.6.2-3
Followup-For: Bug #393454

I'm not sure when my ~/.gv stopped working, but it's not working now.
For example, no matter how I set GV.reverseScrolling (True or False), I
get the same scrolling behavior.  This used to work.

-- System Information:
Debian Release: 4.0
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (700, 'oldstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-686
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages gv depends on:
ii  gs-esp [gs]  8.15.3.dfsg.1-1 The Ghostscript PostScript interpr
ii  libc62.3.6.ds1-13GNU C Library: Shared libraries
ii  libice6  1:1.0.1-2   X11 Inter-Client Exchange library
ii  libsm6   1:1.0.1-3   X11 Session Management library
ii  libx11-6 2:1.0.3-6   X11 client-side library
ii  libxext6 1:1.0.1-2   X11 miscellaneous extension librar
ii  libxmu6  1:1.0.2-2   X11 miscellaneous utility library
ii  libxpm4  1:3.5.5-2   X11 pixmap library
ii  libxt6   1:1.0.2-2   X11 toolkit intrinsics library
ii  xaw3dg   1.5+E-14Xaw3d widget set

gv recommends no packages.

-- no debconf information


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

Bug#385334: ntpd_initres, permission denied error, same here with config file

[Adam M. Costello]

Norbert Preining [EMAIL PROTECTED] wrote:

 I have the same here on my Debian/sid box.  Restart fixes this problem.

I just now saw the same thing with ntp 1:4.2.2.p4+dfsg-1.  I have the
unmodified /etc/ntp.conf, just like Norbert. /etc/init.d/ntp restart
fixed it (for the moment).

AMC


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

Bug#253790: Wondershaper HTB vs CBQ

[Adam M. Costello]

Vince Mulhollon [EMAIL PROTECTED] wrote:

 2) I need to research HTB vs CBQ more...

I recently read up on HTB and found that the HTB version of wondershaper
1.1 wasn't really set up right.  It was trying to use HTB as a drop-in
replacement for CBQ, but there are some fundamental differences.

I tweaked it a bit, and also discovered that disabling TSO is vital.
The final result is working very well for me.  Ping times to the
bottleneck router are about 10/20/50 (min/avg/max ms) even while the web
server is being hammered.

You can see the script at:
http://www.nicemice.net/amc/utils/wondershaper.gz

AMC


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

Bug#356329: kernel: device names are non-deterministic

[Adam M. Costello]

Package: kernel
Severity: important

Whenever I boot my machine, the device names are assigned
non-deterministically.  There is only one disk (SATA), which is
sometimes called /dev/sda and is sometimes called /dev/sdc.  There is a
built-in USB card-reader that also uses sd* names, but there are never
cards plugged in when I boot.  I've seen this phenomenon only with
2.6.15.  With 2.6.12, the disk is always /dev/sda.

There are two ethernet ports and one firewire port.  Sometimes the
ethernets are eth0 and eth1, and the firewire is eth2; sometimes the
firewire is eth0 and the ethernets are eth1 and eth2.  I've definitely
seen this phenomenon on 2.6.15, and I think also on 2.6.12.

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (700, 'oldstable'), (600, 
'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15-1-686
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)


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

Bug#346459: ifupdown: post-down is not the last thing executed

[Adam M. Costello]

Package: ifupdown
Version: 0.6.7
Severity: normal

pre-up commands are the first things executed, before the *-up.d/*
scripts.  But post-down commands are *not* the last things executed.
The *-down.d/* scripts are executed after the post-down commands.  This
is counterintuitive, and makes it difficult to do some things that one
would expect to be easy (for example, load a wireless driver with pre-up
and unload it with post-down).

Suggested fix:  Split execute_all() into two functions, maybe
execute_options() and execute_scripts(), and call them in that order in
iface_up(), and in the opposite order in iface_down().

AMC

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (900, 'testing'), (700, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.8-2-686
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages ifupdown depends on:
ii  debconf [debconf-2.0]   1.4.51   Debian configuration management sy
ii  libc6   2.3.2.ds1-22 GNU C Library: Shared libraries an
ii  net-tools   1.60-13  The NET-3 networking toolkit

-- debconf information:
  ifupdown/convert-interfaces: true


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

Bug#304718: [EMAIL PROTECTED]: Bug#304718: mutt: exim4 deletes bcc field, so maybe it's time to set write_bcc?]

[Adam M. Costello]

Julian Gilbey [EMAIL PROTECTED] wrote:

 It seems that in older versions of mutt, any Bcc header would be
 passed to the sendmail program, whereas in 1.5.9-2 (and presumably
 later versions), the write_bcc option is only made use of when saving
 a message to a mailbox (in mutt_write_rfc822_headers called from
 mutt_write_fcc in sendlib.c), but not when being sent to sendmail.

mutt_write_rfc822_headers() is also called from send.c.

It sure would be nice if mutt could omit the Bcc: when talking to the
MTA but include the Bcc: when writing the Fcc.

I don't know the best way to achieve that.  Here's one person's
suggestion:

http://permalink.gmane.org/gmane.mail.mutt.user/22947

AMC


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

Bug#324891: openssh-client. strange lines in known_host

[Adam M. Costello]

Colin Watson [EMAIL PROTECTED] wrote:

 In fact it's easier than it was before hashing was implemented. See the
 ssh-keygen(1) man page.

Thanks!  Sorry for the false alarm.

AMC


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

Bug#324891: openssh-client. strange lines in known_host

[Adam M. Costello]

Occasionally a host key changes (like when the machine is reinstalled),
and users need to be able to remove the corresonding line from
known_hosts.  Now that the hostnames are hashed, that's difficult.

OpenSSH supposedly comes with utilities remove-knownhost and ssh-showkey
for dealing with this.  Perhaps the next version of the Debian package
should include these.  Until then, I'll just turn off HashKnownHosts in
~/.ssh/config.

AMC


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

Bug#170795: opensp: strange error when parsing an HTML file with onsgmls using stdin

[Adam M. Costello]

Frederic Schutz [EMAIL PROTECTED] wrote:

  1) If I do onsgmls -s test.html, no output, as expected;
  2) If I do cat test.html | onsgmls -s, the same;
  3) but if I do onsgmls -s test.html, I get:
 onsgmls:OSFD0:73:16:E: end tag for UL omitted, but its declaration 
 does not permit this
 onsgmls:OSFD0:58:4: start tag was here

I'm observing something very similar with onsgmls from opensp 1.5.1.0-2.

When I do onsgmls -s  foo.html, there is no output (which is correct).
When I do cat foo.html | onsgmls -s, I get the following on stderr:

onsgmls:OSFD0:108:7:E: end tag for SPAN omitted, but its declaration does 
not permit this
onsgmls:OSFD0:107:0: start tag was here

foo.html is below.  I think it's significant that the span and /span
tags straddle the 8 kB boundary.

AMC

!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01//EN
html
headtitle/title/head
body
p
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx

Bug#307445: mutt: scrolling functions no longer reveal empty space

[Adam M. Costello]

Marco d'Itri [EMAIL PROTECTED] wrote:

 Does set menu_move_off (which is in the default /etc/Muttrc) fixes
 this?

Yes!  Thanks.

In case you're wondering why I didn't inherit menu_move_off from
/etc/Muttrc, I think it's because when I started using mutt years ago,
/etc/Muttrc included some settings that could not be undone, so I wrote
a wrapper that calls mutt -n, but my memory of this is hazy now.  I
guess I should determine whether that's still necessary.

AMC


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

Bug#307445: mutt: scrolling functions no longer reveal empty space

[Adam M. Costello]

Package: mutt
Version: 1.5.9-1
Severity: wishlist

Until recently the functions current-middle, current-top, and next-line
were all capable of revealing empty space below the last message in the
index.

I have long been in the habit, whenever I finish reading all the new
messages, of doing last-entry current-middle, thereby leaving half the
window empty.  This way, as new mail arrives, I can see the one-line
summaries appear without having to touch the window again.  Now, without
the ability to leave empty space, all I can see is New mail in this
mailbox, but I have to grab the mouse and select the window and scroll
up to see the one-line summaries.

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (900, 'testing'), (700, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.8-2-686
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages mutt depends on:
ii  exim4   4.50-4   metapackage to ease exim MTA (v4) 
ii  exim4-daemon-light [mail-tr 4.50-4   lightweight exim MTA (v4) daemon
ii  libc6   2.3.2.ds1-21 GNU C Library: Shared libraries an
ii  libdb4.34.3.27-2 Berkeley v4.3 Database Libraries [
ii  libgnutls11 1.0.16-9 GNU TLS library - runtime library
ii  libidn110.5.13-1.0   GNU libidn library, implementation
ii  libncursesw55.4-4Shared libraries for terminal hand
ii  libsasl22.1.19-1.5   Authentication abstraction library

-- no debconf information


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

Bug#306094: exim4: local part restrictions became inconsistent with comments, changelog is silent

[Adam M. Costello]

Package: exim4
Version: 4.50-4
Severity: minor

Very recently (between 4.50-4 and 4.50-6) the local_parts restrictions
in /etc/exim4/conf.d/acl/30_exim4-config_check_rcpt changed, but the
comments discussing the restrictions did not change, so the actual
restrictions and the explanation are now inconsistent.

Also, the changelog makes no mention of this change.  I'd like to know
the rationale.

Thanks,
AMC

-- Package-specific info:
Exim version 4.50 #1 built 02-Mar-2005 07:41:23
Copyright (c) University of Cambridge 2004
Berkeley DB: Sleepycat Software: Berkeley DB 4.2.52: (December  3, 2003)
Support for: iconv() IPv6 GnuTLS
Lookups: lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmnz dsearch nis 
nis0 passwd
Authenticators: cram_md5 plaintext
Routers: accept dnslookup ipliteral manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore autoreply lmtp pipe smtp
Fixed never_users: 0
Configuration file is /var/lib/exim4/config.autogenerated

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (900, 'testing'), (700, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.8-2-686
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages exim4 depends on:
ii  exim4-base4.50-4 support files for all exim MTA (v4
ii  exim4-daemon-light4.50-4 lightweight exim MTA (v4) daemon

-- no debconf information


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

Bug#303827: mawk: printf %x clamps numbers to range of signed int rather than unsigned int

[Adam M. Costello]

Package: mawk
Version: 1.3.3-11
Severity: normal

[Sorry if this is a duplicate.  I'm not sure whether my first attempt
got through.]

The printf %x conversion is supposed to treat its argument as an
unsigned int (see printf(3)).  But look at what mawk does:

$ mawk 'END { printf(%x %x\n, 2e9, 3e9) }'  /dev/null
77359400 7fff

Compare that to gawk:

$ gawk 'END { printf(%x %x\n, 2e9, 3e9) }'  /dev/null
77359400 b2d05e00

The range of an unsigned int on 32-bit platforms goes up to ,
not 7fff.

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (900, 'testing'), (700, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.8-2-686
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages mawk depends on:
ii  libc6   2.3.2.ds1-20 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#295649: tk8.4: spinbox widget gets stuck in infinite repeat

[Adam M. Costello]

Package: tk8.4
Version: 8.4.9-1
Severity: normal

The bug is in /usr/lib/tk8.4/spinbox.tcl.  It's possible for a spinbox
button to get effectively stuck down so that its action gets invoked
repeatedly until the application is killed.

The B1-Leave event is used to start a repeating chain of AutoScan
invocations, each of which schedules the next one, continuing until
some other event (like a ButtonRelease-1 or a B1-Enter) cancels the
next scheduled invocation, whose ID is stored in Priv(afterId).  The
assumption is that a B1-Leave event means the user dragged from inside
the widget to outside widget, which means the user must be trying to
select a bunch of text, which ought to continue scrolling as long as the
button is held down outside the widget.

But some window managers can cause a B1-Leave event without any
dragging and without any corresponding button release.  In my case,
olvwm allows me to select a window (to give it the focus) by clicking
on it while holding down the WMGrab modifier (which I have configured
to be Control, but I don't think that's relevant).  As a side effect,
this causes a B1-Leave event (I don't know why), but no button
release.  Therefore, a never-ending chain of AutoScan invocations is
launched, with no immediate possibility of a ButtonRelease-1 or
a B1-Enter because the button is not even down.  This background
activity is invisible to the user because it has no effect on the
display.  However...

If the user then clicks on one of the spinbox buttons, the background
chain of AutoScan calls can collide with the chain of Invoke calls,
because both use Priv(afterId) to store the ID of the next scheduled
call.  The button is supposed to trigger its -command action repeatedly
as long as it is held down, and the button release triggers the
cancelation of the next call.  But because the ID is shared, the button
release can instead end up terminating the background chain of AutoScan
calls, leaving the chain of Invoke calls going forever.

To reproduce this effect, run olvwm (or olwm) and the following script:

#!/usr/bin/wish
proc foo {} { puts stderr DEBUG foo }
spinbox .foo -command foo
pack .foo

Click on the spinbox text area while holding down the WMGrab modifier
(which I think is Alt by default), then click on one of the buttons
once or twice.  You should see an endless stream of DEBUG foo on
stderr.  More clues can be gathered by adding debug statements in
/usr/lib/tk8.4/spinbox.tcl.

I think perhaps AutoScan needs to check whether a text selection is
actually in progress (initiated by a button press) rather than assume
that a B1-Leave implies that the button is currently down.  It
would probably also be a good idea to use separate variables to store
AutoScan's after ID and Invoke's after ID.

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (900, 'testing'), (700, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.9-2-686
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages tk8.4 depends on:
ii  libc62.3.2.ds1-20GNU C Library: Shared libraries an
ii  libx11-6 4.3.0.dfsg.1-10 X Window System protocol client li
ii  tcl8.4   8.4.9-1 Tcl (the Tool Command Language) v8
ii  xlibs4.3.0.dfsg.1-10 X Keyboard Extension (XKB) configu

-- no debconf information


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

Bug#290672: tcl8.4: man page lsearch(3tcl) is unviewable, emacs comment confuses man

[Adam M. Costello]

Package: tcl8.4
Version: 8.4.9-1
Severity: minor

The first line of the lsearch(3tcl) man page (unlike all other 3tcl man
pages) begins with a comment intended for emacs:

'\ -*- nroff -*-

Unfortunately man thinks this is directed at itself, indicating
preprocessors to run, and it fails to display the man page.

The same problem exists for the pages toplevel(3tk) and loadTk(3tk)
(and no other 3tk man pages) over in the tk8.4 package (same
version: 8.4.9-1), which I won't report separately unless you ask me to.

AMC

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (900, 'testing'), (700, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.8-1-686
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages tcl8.4 depends on:
ii  libc6   2.3.2.ds1-18 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#290672: tcl8.4: man page lsearch(3tcl) is unviewable, emacs comment confuses man

[Adam M. Costello]

Chris Waters [EMAIL PROTECTED] wrote:

 Hmm, when I try it, I get messages about ignoring unknown
 preprocessor sent to stderr, but the man page itself displays just
 fine.  That would still, I suppose, qualify as a minor bug, but I'm
 curious why it works on my system but not yours...

On closer examination, I can answer that.  The r in -*- nroff -*- is
interpreted as a request for the refer preprocessor, which comes with
the groff package, not the groff-base package.  Apparently your system
has both packages installed, but mine has only the latter.

AMC


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