Bug#787034: Further details: .wav files causing problems
> On Sat, Aug 24, 2019 at 06:01:18PM -0500, Tim Chase wrote: > > I've posted the file in question to [snip] > > I got it, thanks. Which version of the cmus package do you have > installed? I can't reproduce it with your file under the latest > version of cmus in unstable: > > rak@zeta:~$ dpkg-query -W 'cmus*' > cmus2.8.0-1 > cmus-plugin-ffmpeg 2.8.0-1 Indeed, while it was an issue back when I posted it in 2005: Package: cmus Version: 2.5.0-7+b1 ⋮ Versions of packages cmus recommends: ii cmus-plugin-ffmpeg 2.5.0-7+b1 I'm not sure the magic bug-tracker incantation to close this, but it's now appears to be fixed in the most recent version: $ dpkg-query -W 'cmus*' cmus2.7.1+git20160225-1+b2 cmus-plugin-ffmpeg 2.7.1+git20160225-1+b2 where the same file no longer crashes cmus/cmus-plugin-ffmpeg. Thanks! -tim
Bug#910483: ttf-mscorefonts-installer infinite loop if SourceForge.net CA-chain isn't trusted
Package: ttf-mscorefonts-installer Version: 3.6 File: ttf-ms Severity: normal Dear Maintainer, > What led up to the situation? $ sudo dpkg-reconfigure ca-certificates and disable "mozilla/DST_Root_CA_X3.crt" (by default I disable the majority of CAs) then $ sudo apt-get install ttf-mscorefonts-installer > What exactly did you do (or not do) that was effective (or > ineffective)? $ sudo dpkg-reconfigure ca-certificates and re-enable "mozilla/DST_Root_CA_X3.crt" to get it working again. > What was the outcome of this action? Attempting an install without the DST_Root_CA_X3 enabled led to an infinite loop in the installer. Reenabling the (previously-revoked) trust in the CA install proceeded properly. > What outcome did you expect instead? If the curl/wget command fails because the root CA is not trusted, it should abort/fail the install, preferrably with a message about the CA chain-of-trust it was expecting, and a suggestion to "dpkg-reconfigure ca-certificates" (or export $CURL_CA_BUNDLE to an appropriate value for the process or whatever the analog would be for `wget`). But certainly not an infinite loop. Thanks, -Tim -- System Information: Debian Release: 9.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-6-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages ttf-mscorefonts-installer depends on: ii cabextract 1.6-1+b1 ii debconf [debconf-2.0] 1.5.61 ii wget 1.18-5+deb9u2 ii xfonts-utils 1:7.7+4 Versions of packages ttf-mscorefonts-installer recommends: ii fonts-liberation 1:1.07.4-2 ttf-mscorefonts-installer suggests no packages. -- debconf-show failed
Bug#799943: rlwrap: use of readline macros crashes with SIGSEGV
On 2015-09-28 09:17, Mike Miller wrote: > Confirmed, but only if the macro contains at least two newlines. The > minimal test case is: C-x ( C-x ) C-x e > > Able to reproduce with upstream git master branch as well. Upstream > has already opened an issue tracker for this, please follow up > there with further comments or patches. I think the problem may actually reside in a readline library since I get the same issue in Python (2.7 and 3.4) which uses readline under the covers: $ python >>> import cmd >>> cmd.Cmd().cmdloop() (Cmd) # do C-x ( C-x ) C-x e and it segfaults -Tim
Bug#799943: rlwrap: use of readline macros crashes with SIGSEGV
Package: rlwrap
Version: 0.41-1
Severity: important
Dear Maintainer,
> * What led up to the situation?
Attempting to use readline macros, playback crashed
> * What exactly did you do (or not do) that was effective (or
> ineffective)?
To reproduce the issue start up
rlwrap cat
then issue "control+X, (" to start recording a macro. Enter
two lines of text
hello there
this is a test
(they will be echoed, obviously) Stop recording the macro
with "control+X, )".
When attempting to play back the macro with "control+X, e",
rlwrap crashes with a SIGSEGV
$ rlwrap cat
Before typing this line, I hit control+x followed by "("
Before typing this line, I hit control+x followed by "("
And am about to hit control+x followed by ")"
And am about to hit control+x followed by ")"
Now about to hit control+x followed by "e"
Now about to hit control+x followed by "e"
rlwrap: Oops, crashed (caught SIGSEGV) - this should not
have happened! If you need a core dump, re-configure
with --enable-debug and rebuild
Resetting terminal and cleaning up...
> * What was the outcome of this action?
The SIGSEGV
> * What outcome did you expect instead?
With the recorded macro, it should have retyped the first
two lines when playback was invoked.
I discovered the bug when using ed(1) but cat(1) was an
easier case to reproduce.
-- System Information:
Debian Release: 8.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
(ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked
to /bin/dash Init: systemd (via /run/systemd/system)
Versions of packages rlwrap depends on:
ii libc6 2.19-18+deb8u1
ii libreadline6 6.3-8+b3
ii libtinfo5 5.9+20140913-1+b1
ii perl 5.20.2-3+deb8u1
rlwrap recommends no packages.
rlwrap suggests no packages.
-- no debconf information
Bug#787034: Further details: .wav files causing problems
On 2015-05-28 18:31, Fabian Greffrath wrote: Am Donnerstag, den 28.05.2015, 09:58 -0500 schrieb Tim Chase: $ file ~/tmp/music/under-dog-theme.wav /home/tim/tmp/music/under-dog-theme.wav: RIFF (little-endian) data, WAVE audio, MPEG Layer 3, mono 11025 Hz ^^ Erm, somehow this reads wrong for a WAV file. I wondered about that. It has played just fine in the past on multiple machines and programs including cmus. I understand that RIFF is a container format that can hold MPEG/3 and PCM data. $ xxd ~/tmp/music/under-dog-theme.wav | head -3 000: 5249 4646 ba4d 0100 5741 5645 666d 7420 RIFF.M..WAVEfmt 010: 1e00 5500 0100 112b c409 U+.. 020: 0100 0c00 0100 0200 0401 0200 which is clearly RIFF rather than MP3. At your nudging, a quick renaming it to .mp3 works without crashing. So there appear to be two related issues: 1) a file with a .wav extension can apparently be a RIFF file containing MPEG/3 data 2) cmus can segfault on data it doesn't understand rather than gracefully logging/ignoring the problem file So this is would no longer be important priority since the footprint of the bug is far smaller; rather it's just normal priority as it seems to be a narrow edge case (I'm insufficiently familiar with BTS, but I *think* I managed to change this in a previous email to control@). -Tim -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787034: Further details: .wav files causing problems
The directory in question has a variety of media including .mp3, .ogg, and .wav so as an experiment, I created an isolated directory and copied one media file into it until it crashed. While the .mp3 and .ogg worked fine, a single .wav file was enough trigger the segfault. $ rm -rf ~/.cmus ~/tmp/music $ mkdir -p ~/tmp/music $ cp $MEDIA_DIR/under-dog-theme.wav ~/tmp/music $ file ~/tmp/music/under-dog-theme.wav /home/tim/tmp/music/under-dog-theme.wav: RIFF (little-endian) data, WAVE audio, MPEG Layer 3, mono 11025 Hz $ cmus :add ~/tmp/music [Segmentation fault] I can provide the .wav in question if needed (though there might be copyright considerations). It doesn't seem to crash on every .wav file as I have others that play just fine. Based on file(1) output, the ones that play fine are RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, mono 44100 Hz (the rate varies, so some are 44100 Hz while others are half that) -Tim -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787034: cmus: Adding a folder of music triggers a segmentation fault
Package: cmus Version: 2.5.0-7+b1 Severity: important Dear Maintainer, * What led up to the situation? upgraded from Wheezy to Jessie * What exactly did you do (or not do) that was effective (or ineffective)? 0) tried running cmus, segfaulted 1) renamed my ~/.cmus folder so it wasn't found 2) ran cmus (got the empty play-list as expected) 3) used 5 to browse to my folder of music 4) used a to add the folder Instead of #3-4, I can try using :a /path/to/music and get the same segfault results. * What was the outcome of this action? Some unknown quantity of files were added to the playlist before segfaulting * What outcome did you expect instead? I expected my music to be added to the playlist (which is what happened successfully in cmus in Wheezy, but is now failing in Jessie). I'd be glad to test with any sort of debugging options that might help track down the issue. -Tim -- System Information: Debian Release: 8.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages cmus depends on: ii libao4 1.1.0-3 ii libasound2 1.0.28-1 ii libc6 2.19-18 ii libcddb21.3.2-5 ii libcdio-cdda1 0.83-4.2 ii libcdio13 0.83-4.2 ii libcue1 1.4.0-1 ii libfaad22.7-8 ii libflac81.3.0-3 ii libmad0 0.15.1b-8 ii libmodplug1 1:0.8.8.4-4.1+b1 ii libmpcdec6 2:0.1~r459-4.1 ii libncursesw55.9+20140913-1+b1 ii libtinfo5 5.9+20140913-1+b1 ii libvorbisfile3 1.3.4-2 ii libwavpack1 4.70.0-1 Versions of packages cmus recommends: ii cmus-plugin-ffmpeg 2.5.0-7+b1 ii libpulse0 5.0-13 ii libroar21.0~beta11-1 cmus 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#775647: ed: Use upstream red script rather than symbolic link
Subject: ed: Use upstream red script rather than link Package: ed Version: 1.6-2 Severity: normal Dear Maintainer, With the upstream change from v1.4 to v1.5, ed(1) no longer recognizes red as a name under which restricted mode will be invoked. $ echo hello example.txt $ # errant behavior $ red example.txt 6 e /etc/passwd 4210 !pwd /home/tim ! q $ # correct behavior that should also happen with red $ ed -r example.txt 6 e /etc/passwd ? !pwd ? q As a workaround, ed -r can be used instead. Prior to ed(1) v1.5, the symbolic link sufficed. However, since v1.5, it's now a shell-script that is provided as part of the build process. http://download.savannah.gnu.org/releases/ed/ If including v1.5 or later, the solution is to use the red shell-script from the upstream package build rather than using a symlink. -Tim -- System Information: Debian Release: 7.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages ed depends on: ii dpkg 1.16.15 ii install-info 4.13a.dfsg.1-10 ii libc6 2.13-38+deb7u6 ed recommends no packages. ed 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#775647: Acknowledgement (ed: Use upstream red script rather than symbolic link)
On 2015-01-18 02:09, Debian Bug Tracking System wrote: If you wish to submit further information on this problem, please send it to 775...@bugs.debian.org. I can't tell from this (closed) bug-report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=710865 whether this was the same issue and/or if it was actually fixed. However, since there are security implications, I would recommend switching from the symlink to the upstream red(1) shell-script in Stable as well as any changes that may have gone into Testing/Sid. -Tim -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774009: speech-dispatcher-festival: docs reference nonexistant /etc/init.d/festival file
Package: speech-dispatcher-festival
Version: 0.7.1-6.2
Severity: minor
Dear Maintainer,
The documentation at
/usr/share/doc/speech-dispatcher-festival/README.Debian
states that
In order to use Speech Dispatcher with Festival (which is recommended), you
must have installed this package (or the packages it depends on) and the
Festival server started. To achieve the latter, you must start the server
either by hand such as running
festival --server
on a command line or in some script, or you must comment out the
exit 0
line in the /etc/init.d/festival file.
No such /etc/init.d/festival file exists in any of the
- speech-dispatcher
- speech-dispatcher-festival
- festival
packages:
$ dpkg -L speech-dispatcher{,-festival} festival | grep /etc/init.d
/etc/init.d
/etc/init.d/speech-dispatcher
Resolution would involve one of
1) creating an /etc/init.d/festival containing such an exit 0 line
2) update the README.Debian with corrected instructions
-- System Information:
Debian Release: 7.7
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages speech-dispatcher-festival depends on:
ii festival 1:2.1~release-5.1
ii festival-freebsoft-utils 0.10-3
ii speech-dispatcher 0.7.1-6.2
Versions of packages speech-dispatcher-festival recommends:
ii sound-icons 0.1-3
speech-dispatcher-festival 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#718422: elvis: -c open at startup fails to start in open mode
Package: elvis Version: 2.2.0-11.1 Severity: normal Dear Maintainer, The man pages state the -c command should act like issuing :command after the first buffer has been opened. However, starting elvis with bash$ elvis -c open myfile.txt doen't actually switch to open mode like bash$ elvis myfile.txt :open does. I've tried it with +open, -c :open, and +:open, none of which switch to open mode in the same way as manually executing the :open ex command. Either the docs need to be updated to reflect what can/can't be issued as an ex command, or elvis should be updated to actually perform as advertised in the docs. -Tim Chase -- System Information: Debian Release: 7.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (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 elvis depends on: ii elvis-common 2.2.0-11.1 ii libc6 2.13-38 ii libncurses5 5.9-10 ii libx11-6 2:1.5.0-1+deb7u1 ii libxft2 2.3.1-1 ii libxpm4 1:3.5.10-1 elvis recommends no packages. Versions of packages elvis suggests: pn elvis-tools 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#503227: abiword: Upgrading to 2.6.4 turned all text garbled
Package: abiword Version: 2.6.4-5 Followup-For: Bug #503227 Experiencing the same as other folks here with this bug. Before upgrading (not sure what the previous version was), text showed up fine. However, it's now all smashed together. Checked for kerning/leading oddness, but everything was set correctly. Also tried removing my ~/.AbiWord settings directory, but it didn't help. This may also be a dupe of #495738/#495927 Off to test with ttf-liberation as suggested in #503227. -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.24-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 abiword depends on: ii abiword-commo 2.6.4-5efficient, featureful word process ii gsfonts 1:8.11+urwcyr1.0.7~pre43-2 Fonts for the Ghostscript interpre ii libaiksaurus- 1.2.1+dev-0.12-5 an English-language thesaurus (dev ii libaiksaurusg 1.2.1+dev-0.12-5 graphical interface to the Aiksaur ii libart-2.0-2 2.3.20-2 Library of functions for 2D graphi ii libatk1.0-0 1.22.0-1 The ATK accessibility toolkit ii libc6 2.7-10 GNU C Library: Shared libraries ii libcairo2 1.6.4-7The Cairo 2D vector graphics libra ii libenchant1c2 1.4.2-3.3 a wrapper library for various spel ii libexpat1 1.95.8-4 XML parsing C library - runtime li ii libfontconfig 2.5.0-2generic font configuration library ii libfreetype6 2.3.5-1+lenny1 FreeType 2 font engine, shared lib ii libfribidi0 0.10.9-1 Free Implementation of the Unicode ii libgcc1 1:4.3.1-2 GCC support library ii libglade2-0 1:2.6.2-1 library to load .glade files at ru ii libglib2.0-0 2.16.3-2 The GLib library of C routines ii libgnomecanva 2.20.1.1-1 A powerful object-oriented display ii libgnomeprint 2.18.4-1 The GNOME 2.2 print architecture - ii libgnomeprint 2.18.2-1 GNOME 2.2 print architecture User ii libgoffice-0- 0.4.2-4Document centric objects library - ii libgsf-1-114 1.14.8-1 Structured File Library - runtime ii libgtk2.0-0 2.12.11-4 The GTK+ graphical user interface ii libice6 2:1.0.4-1 X11 Inter-Client Exchange library ii libidn11 1.8+20080606-1 GNU libidn library, implementation ii libjpeg62 6b-14 The Independent JPEG Group's JPEG ii libloudmouth1 1.3.4-1Lightweight C Jabber library ii libncurses5 5.7+20081213-1 shared libraries for terminal hand ii libots0 0.5.0-1Open Text Summarizer (library) ii libpango1.0-0 1.20.3-2 Layout and rendering of internatio ii libpixman-1-0 0.10.0-2 pixel-manipulation library for X a ii libpng12-01.2.27-1 PNG library - runtime ii libpopt0 1.14-3 lib for parsing cmdline parameters ii libreadline5 5.2-3 GNU readline and history libraries ii librsvg2-22.22.2-2 SAX-based renderer library for SVG ii libsm62:1.0.3-2 X11 Session Management library ii libstdc++64.3.1-2The GNU Standard C++ Library v3 ii libwmf0.2-7 0.2.8.4-6 Windows metafile conversion librar ii libwpd8c2a0.8.14-1 Library for handling WordPerfect d ii libwpg-0.1-1 0.1.2-1WordPerfect graphics import/conver ii libwv-1.2-3 1.2.4-2Library for accessing Microsoft Wo ii libx11-6 2:1.1.4-2 X11 client-side library ii libxcb-render 0.2.1+git1-1 utility libraries for X C Binding ii libxcb-render 1.1-1.1X C Binding, render extension ii libxcb1 1.1-1.1X C Binding ii libxft2 2.1.12-3 FreeType-based font drawing librar ii libxml2 2.6.32.dfsg-2 GNOME XML library ii libxrender1 1:0.9.4-2 X Rendering Extension client libra ii zlib1g1:1.2.3.3.dfsg-12 compression library - runtime Versions of packages abiword recommends: ii abiword-help 2.4.6-5online help for AbiWord ii abiword-plugin-grammar2.6.4-5grammar checking plugin for AbiWor ii abiword-plugin-mathview 2.6.4-5equation editor plugin for AbiWord ii aspell-en [aspell-dictionary] 6.0-0-5.1 English dictionary for GNU Aspell ii xpdf-utils [poppler-utils]3.02-1.4 Portable Document Format (PDF) sui Versions of packages abiword suggests: pn
Bug#503227: Info received (abiword: Upgrading to 2.6.4 turned all text garbled)
After installing ttf-liberation everything became ungarbled. Looks like ttf-liberation should be a dependency of AbiWord, or AbiWord should handle other fonts more gracefully. -Tim Chase -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507251: dillo: IPv6 doesn't properly fall-back to IPv4 if network is unreachable
Package: dillo Version: 0.8.6-3 Severity: important Pointing Dillo at docs.python.org DNS returns an IPv6 address back: Connecting to 2001:888:2000:d::a2 However, if IPv6 is enabled on the Debian box, but the currently- connected ISP doesn't route IPv6, Dillo fails to load the page with: Http_connect_socket ERROR: Network is unreachable In this case, properly behaved programs should fallback to IPv4 which correctly resolves. Dillo doesn't, making docs.python.org inaccessible to me unless I totally disable IPv6 on my machine or change browsers. I can reach docs.python.org just fine with Lynx, Epiphany and FireFox/IceWeasel (and Safari from my Mac) but Dillo is my preferred help-browser for Python docs on Debian. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.24-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 dillo depends on: ii libc6 2.7-10GNU C Library: Shared libraries ii libfontconfig1 2.5.0-2 generic font configuration library ii libfreetype6 2.3.5-1+lenny1FreeType 2 font engine, shared lib ii libgcc11:4.3.1-2 GCC support library ii libglib1.2ldbl 1.2.10-19 The GLib library of C routines ii libgtk1.2 1.2.10-18.1 The GIMP Toolkit set of widgets fo ii libjpeg62 6b-14 The Independent JPEG Group's JPEG ii libpng12-0 1.2.27-1 PNG library - runtime ii libssl0.9.80.9.8g-10.1 SSL shared libraries ii libstdc++6 4.3.1-2 The GNU Standard C++ Library v3 ii libx11-6 2:1.1.4-2 X11 client-side library ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar ii libxft22.1.12-3 FreeType-based font drawing librar ii libxi6 2:1.1.3-1 X11 Input extension library ii libxrender11:0.9.4-2 X Rendering Extension client libra ii wget 1.11.4-1 retrieves files from the web ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime dillo recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489260: dfm: auto-update uses close to 100% CPU
Package: dfm Version: 0.99.9-1+b1 Severity: normal after launching DFM from my .fluxbox/startup or command-line with dfm CPU usage is fine at this point. After about 40-45 seconds of almost zero CPU usage, the CPU usage for DFM rockets up to heavy usage and stays there until the process is killed. This seems to be related to the 40 second update/refresh period set in the DFM configuration. Before upgrading my version of DFM, refresh happened at 40 seconds with no problems. Since the upgrade, it has caused the heavy CPU usage. Changing the DFM update frequency to 0 disables auto-update, and prevents the CPU utilization from sky-rocketing. However, auto-update now seems to be broken. I've tried leaving it for 5+ minutes to see if it would solve itself, but it remains at high usage indefinitely until killed. Output from top: -- Tasks: 87 total, 2 running, 85 sleeping, 0 stopped, 0 zombie Cpu(s): 4.1%us, 2.2%sy, 0.0%ni, 93.5%id, 0.2%wa, 0.0%hi, 0.0%si, 0.0%st Mem:305136k total, 258276k used,46860k free, 4772k buffers Swap: 289160k total, 204k used, 288956k free,94280k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 18705 tim 20 0 6016 1728 1112 R 88.7 0.6 3:17.83 dfm -- a check of the output of ps axf shows that the DFM process has no child-processes, and is in the Running state: PID TTY STAT TIME COMMAND 18705 ?R 4:19 /usr/bin/dfm The high CPU usage is also shown by wmtop which graphically shows DFM with high CPU utilization. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.24-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 dfm depends on: ii libc6 2.7-10GNU C Library: Shared libraries ii libglib1.2ldbl 1.2.10-19 The GLib library of C routines ii libgtk1.2 1.2.10-18.1 The GIMP Toolkit set of widgets fo ii libx11-6 2:1.1.4-2 X11 client-side library ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar ii libxi6 2:1.1.3-1 X11 Input extension library ii libxpm41:3.5.7-1 X11 pixmap library ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime dfm recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460690: dillo controls-toggle (CTRL+H) regression
Package: dillo Version: 0.8.6-1 Severity: normal In a prior release (I don't have the previous version since I did an upgrade/update) when not in a text-field in Dillo, using CTRL+H toggled the window chrome/controls. In 0.8.6-1, the controls can still be toggled via the mouse by double-clicking on the page background or clicking on the small icon in the bottom-right corner of the window. Since upgrading to 0.8.6-1, the keyboard-only alternative no longer works. The use of CTRL+H is detailed at the bottom of http://www.dillo.org/dillo-help.html All other keyboard controls seem to still work. -Tim Chase -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
