Bug#989735: Minicom 2.8-2 working well

On Tuesday 15 June 2021 at 03:51:03 +, Debian Bug Tracking System wrote: > This is an automatic notification regarding your Bug report > which was filed against the minicom package: > > #989735: minicom: stack smashing when searching in history buffer > > It has been closed by Debian FTP

Bug#989735: minicom: stack smashing when searching in history buffer

Hi Adam, On Monday 14 June 2021 at 09:16:51 +0200, Adam Lackorzynski wrote: > Ok, thanks. Meantime I changed all of this static memory handling to be > more dynamic, also addressing this case I believe. The 'magic' constant > is gone, so hopefully any of those cases. Thanks for the extremely

Bug#989735: minicom: stack smashing when searching in history buffer

On Sunday 13 June 2021 at 21:22:32 +0200, Adam Lackorzynski wrote: > thanks again. I wonder why it did not reproduce for me earlier. > Could you try attached patch and report back? Hi Adam, Thanks for the patch. It did seem better. However, when I do a case-insensitive search I now get:

Bug#989735: minicom: stack smashing when searching in history buffer

Hi Adam, Thanks for the speedy response. On Sunday 13 June 2021 at 17:25:20 +0200, Adam Lackorzynski wrote: > Hi, > > thanks for the report. The issue has always been there and had to do > with the width of minicom's window (over 256 columns). I have addressed > this. Aha. I switched font at a

Bug#989735: minicom: stack smashing when searching in history buffer

Package: minicom Version: 2.8-1 Severity: important Steps to reproduce: 1. Start Minicom connected to a serial port with MINICOM="-m -c on -8" (although I was also able to reproduce the problem with MINICOM="" if the keystrokes below are changed appropriately.) 2. Cause whatever is connected to

Bug#973884: Improved patch

17 00:00:00 2001 From: Mike Crowe Date: Fri, 6 Nov 2020 15:22:37 + Subject: [PATCH] [SV 45763] Fix large command line on POSIX systems When presented with a very long command line (as is common when linking a large number of files with absolute paths in a deep subdirectory), make fa

Bug#973884: make-dfsg: fix for extraordinarily-long command lines (#688601) has gone missing

=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled commit f079489160d620e5eb50dc09e51f09f71a7dcffb Author: Mike Crowe Date: Fri Nov 6 15:22:37 2020 + Resurrect fix for large command line

Bug#941804: exim4: remote_smtp_smarthost transport does not set DKIM variables

Package: exim4 Version: 4.92-8+deb10u3 Severity: wishlist The remote_smtp transport in /etc/exim4/conf.d/transport/30_exim4-config_remote_smtp contains lines like: .ifdef DKIM_PRIVATE_KEY dkim_private_key = DKIM_PRIVATE_KEY .endif to set the DKIM variables based on macro values. These lines

Bug#309278: taglib now generates files that id3v2 can't read

It appears that Buster's version of taglib: ii libtag1v5:amd64 1.11.1+dfsg.1-0.3 amd64audio meta-data library now writes ID3v2.4 tags by default (and uses the new UTF-8 text encoding too.) This means that any program that uses this library (lots of KDE perhaps?) will make

Bug#930350: Not related to the Media Player Indicator extension

I disabled the Media Player Indicator extension in Tweaks, yet the play/pause button has just stopped working again. I probably should have mentioned earlier that I'm running on Wayland. This appears to mean that I can't try restarting gnome-shell to see if that fixes the problem. Mike.

Bug#930350: Reboot not required to fix

It appears that normal behaviour of the play/pause button returns if I log out and log back in again. A full reboot is not required. Mike.

Bug#930350: gnome-shell: Play/pause keyboard button stops controlling Rhythmbox/Totem

Package: gnome-shell Version: 3.30.2-9 Severity: normal I use Totem to listen to long media files and pause/resume them using the Play/Pause button on my keyboard. After a while (sometimes a few hours, sometimes a few days) this button stops working. Pressing it has no effect on Totem, Rhythmbox

Bug#925496: Fix available upstream

Control: tags -1 + fixed-upstream The workaround is included in upstream v4.19.35 onwards: b787544dc5e707fec86161b881391eb9342806e6. Mike.

Bug#926164: Totem still sort of running, just UI not responding

It's just happened to me again and I was able to collect some more details. 1. The play/pause media key on my keyboard can still be used to play/pause the track. 2. The "Videos is not responding" popup appears over the Totem window when I try to focus it. 3. I captured the following strace when

Bug#926164: totem: Totem UI freezes after a while when playing or paused with long M4A file

Package: totem Version: 3.30.0-4 Severity: normal Since upgrading to Buster recently, the Totem user interface has started hanging whilst I listen to M4A audio files that are several hours long. Sometimes it does so whilst playing (playback continues) and sometimes whilst paused. The user

Bug#925496: Fix pending upstream

Control: found -1 linux/4.19.28-2 Control: tags -1 + patch The upstream maintainer has provided a workaround[1] for this which has apparently been queued[2] for stable, so I imagine that the fix will be merged in due course. Mike. [1]

Bug#925496: Problem comes back with "EPU Power Saving Mode" enabled in the BIOS

Control: reopen -1 Control: found linux/4.19.28-2 Control: tags upstream I wrote: > However, this inspired me to check the BIOS version on the Asus H87M-E > motherboards we're using. Both were using the rather ancient version > 1001. I upgraded one machine to the latest version 2201 and the

Bug#925496: Introduced between v4.18 and v4.19, not fixed in v5.0

I've tested some other kernel versions. In the description below, "fast" means that the NFS clients booted quickly (~20s) whereas "slow" means that the NFS clients booted slowly (~100s). In all cases, rx-usecs=200, rx-frames=4. Debian versions: v4.18.0-3-amd64: fast (not tested recently)

Bug#925496: linux-image-4.19.0-2-amd64: Latency increase with r8169 and default coalescing settings

Package: src:linux Version: 4.19.16-1 Severity: normal After upgrading the "server" from Stretch to Buster, performance of our embedded client devices which mount their root filesystem over NFSv2 from said server dropped considerably. The time from mount to full system operation of these clients

Bug#914816: tmux: split-window/new-window behaviour changed when PWD differs from caller current directory

Package: tmux Version: 2.8-1 Severity: normal Dear Maintainer, tmux 2.8 contains a change in behaviour compared to previous versions when the current directory differs from the contents of the PWD environment variable: Consider running the following at a shell prompt in a tmux session: cd /

Bug#869886: Problem goes away when downgrading to Jessie 3.16 kernel

Previously, I wrote: > A few days after upgrading to Stretch and its 4.9 kernel we got an RCU > stall in the middle of the night: A series of very-similar-looking RCU stalls happened again a week later. The machine is under moderate load most of the time. I switched to running Jessie's kernel,

Bug#869886: linux-image-4.9.0-3-amd64: rcu_sched self-detected stall on CPU in nfs_reap_expired_delegations

Package: src:linux Version: 4.9.30-2+deb9u2 Severity: important Dear Maintainer, This particular machine has successfully been running Debian for many years, through Lenny to Jessie. It looks like I needed to add "nointremap" to the kernel command line when it was upgraded to Wheezy back in

Bug#820916: Permissions problem with destination?

I ran into what appeared to be an identical deadlock today when rsyncing a directory hierarchy between two local directories. I too had all three rsync processes all stuck inside a select system call with a sixty second timeout. I was executing: rsync --delete-before --exclude 'pattern.*' -vat

Bug#771441: tftpd-hpa fails to start properly if network is unavailable

On Friday 27 January 2017 at 09:48:22 +0100, Uwe Kleine-König wrote: > Independent of this changing the default TFTP_ADDRESS to ":69" to get > ipv6 connectivity would be nice. Or maybe still better to ":tftp". Indeed. As I wrote in message #95, the debconf question for TFTP_ADDRESS even implies

Bug#844206: dgit: should offer suggestions when attempting to clone a binary package name

Package: dgit Version: 1.0 Severity: wishlist I recently tried to run: dgit clone tftpd-hpa I was greeted with: canonical suite name for unstable is sid starting new git history no version available from the archive dgit: package tftpd-hpa does not exist in suite unstable It turns out

Bug#771441: Corrected patch

On Sat, 29 Nov 2014 16:09:09 +, I wrote: > The attached patch is my attempt to change the default. Unfortunately, I appear to have generated the patch backwards which is somewhat confusing. I hope that this one is correct. Mike. diff -ruN tftp-hpa-5.2+20150808.before/debian/po/cs.po

Bug#771441: I don't believe that NetworkManager is at fault here

On Thursday 06 October 2016 at 13:01:07 +1030, Ron wrote: > > The current tftpd-hpa package defaults to being available on all interfaces > > via an IPv4 address. In Message #25, Ron rightly questioned whether this is > > still a sensible default. But, as I said in Message #30, I don't believe > >

Bug#771441: I don't believe that NetworkManager is at fault here

[It seems that I forgot to subscribe to this bug so I didn't see that there had been activity since the original exchange.] In Message #75 2015-05-22 13:35 GMT+02:00 Ron wrote: > It's not only tftp-hpa that would get burned by this. Any network > using service that needs to

Bug#795909: emacs24: Hang with large yanks

Package: emacs24 Version: 24.4+1-5 Severity: normal Tags: upstream patch Dear Maintainer, Emacs 24.4 and 24.5 suffer from a signal-handling bug which can cause X11 Emacs to hang during a paste/yank operation. This was reported as an Emacs bug at http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16737

Bug#777683: Disabling TSO may avoid the problem

I seem to be seeing the same problem on: 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1 (2015-05-24) x86_64 GNU/Linux with: 00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network Connection (rev 05) Subsystem: Intel Corporation Device 2002 Flags: bus master, fast

Bug#779350: linux-image-3.2.0-4-amd64: Bridge no longer passes some multicast packets

Package: src:linux Version: 3.2.65-1+deb7u2 Severity: normal Dear Maintainer, Upon upgrading my linux-image-3.2.0-4-amd64 package from 3.2.65-1+deb7u1 to 3.2.65-1+deb7u2 it appears that my bridge device is no longer able to pass (at least some) multicast packets. I've reproduced the problem on

Bug#771441: tftpd-hpa fails to start properly if network is unavailable

On Sunday 30 November 2014 at 08:05:46 +1030, Ron wrote: On Sat, Nov 29, 2014 at 08:32:05PM +, Mike Crowe wrote: But I don't think that the default of :69 is any worse than 0.0.0.0:69 would be though - unless you have a deep distrust of anyone on IPv6. :) Right, I'm not saying it's

Bug#771441: tftpd-hpa fails to start properly if network is unavailable

Package: tftpd-hpa Version: 5.2+20140608-3 Severity: important Tags: patch Dear Maintainer, When a Wheezy or Jessie machine is fitted with an SSD the machine often boots so quickly that tftpd-hpa is started before the network is fully configured. The problem is reproducible with sysvinit (on

Bug#771441: tftpd-hpa fails to start properly if network is unavailable

Hi Ron, Thanks for quick response. On Sunday 30 November 2014 at 05:25:10 +1030, Ron wrote: On Sat, Nov 29, 2014 at 04:09:09PM +, Mike Crowe wrote: Package: tftpd-hpa Version: 5.2+20140608-3 Severity: important Tags: patch Dear Maintainer, When a Wheezy or Jessie machine

Bug#771441: tftpd-hpa fails to start properly if network is unavailable

On Sunday 30 November 2014 at 06:40:26 +1030, Ron wrote: On Sat, Nov 29, 2014 at 07:14:16PM +, Mike Crowe wrote: On Sunday 30 November 2014 at 05:25:10 +1030, Ron wrote: On Sat, Nov 29, 2014 at 04:09:09PM +, Mike Crowe wrote: When a Wheezy or Jessie machine is fitted with an SSD

Bug#528950: Fixed in Jessie by 3.8.2-1

It looks like 3.8.2-1 was uploaded by Torsten Landschoff in August 2014 which fixes this bug. 3.8.2-2 will be in Jessie. I've installed 3.8.2-2 on Wheezy (it installs without any dependency problems) and it seems to be behaving as well as my locally-patched 3.8.1 did. So, I think we can close

Bug#770326: totem: gnome-open causes totem to display recently played files rather than playing the desired file

Package: totem Version: 3.14.0-2 Severity: normal Dear Maintainer, Steps to reproduce: 1. Ensure that Totem is not running. 2. At a shell prompt enter: gnome-open 2014-11-15-172942.webm 3. Notice that Totem starts up but shows some sort of overview of available media files rather than

Bug#770326: totem: gnome-open doesn't even start totem on Sid

My original report was for my laptop running Jessie. I've just tried the same thing on a VM running up-to-date Sid. On Sid all the reproduction steps have no effect on Totem at all (i.e. Totem is not started if it wasn't already running and a running Totem just continues with whatever it was

Bug#754354: Something holds dentry-related mutex forever in Wheezy amd64 kernel

On Sunday 28 September 2014 at 15:01:21 +0100, Ben Hutchings wrote: On Sat, 2014-09-27 at 19:41 +0100, Mike Crowe wrote: I compiled my own version of the Debian 3.2.60-1+deb7u3 kernel with CONFIG_LOCKDEP and panic on hung task enabled. From the crash dump: [25202.156175] INFO: task

Bug#754354: Something holds dentry-related mutex forever in Wheezy amd64 kernel

I compiled my own version of the Debian 3.2.60-1+deb7u3 kernel with CONFIG_LOCKDEP and panic on hung task enabled. From the crash dump: [25202.156175] INFO: task nfsd:3247 blocked for more than 900 seconds. [25202.162565] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message.

Bug#733059: gnome-screensaver cannot be launched by alternative gnome-session

On Thursday 31 July 2014 at 10:56:39 +0100, Simon McVittie wrote: On Sun, 18 May 2014 at 20:36:42 +0100, Mike Crowe wrote: gnome-settings-daemon, nm-applet and (my) i3-gnome are launched correctly yet gnome-screensaver is not. This appears to be due to the following line in /usr/share/gnome

Bug#754354: Something holds dentry-related mutex forever in Wheezy amd64 kernel

On Monday 21 July 2014 at 15:01:31 +0100, Mike Crowe wrote: It is possible that I'm seeing the same problem. Our AMD Opteron 4386 (16 cores) machine is also getting stuck with lots of hung tasks. [snip] PID: 4087 TASK: 88040ea63840 CPU: 2 COMMAND: nfsd #0 [8804034b9c00

Bug#754354: Something holds dentry-related mutex forever in Wheezy amd64 kernel

It is possible that I'm seeing the same problem. Our AMD Opteron 4386 (16 cores) machine is also getting stuck with lots of hung tasks. Although it responds to ping, and even a KVM virtual machine running on it appears to continue working correctly, the host itself is locked up. This happens once

Bug#752779: nm-connection-editor hangs if home directory contains symlinks to NFS mounts

Package: network-manager-gnome Version: 0.9.8.10-1 Severity: normal File: /usr/bin/nm-connection-editor I managed to get my network configuration into something of a pickle by accidentally removing my main network connection using nm-connection-editor. Once I'd done that I was unable to re-create

Bug#733059: gnome-screensaver cannot be launched by alternative gnome-session

I'm not absolutely sure that this is what the original reporter meant but I've just run into this problem when using gnome-session to launch my own i3-gnome session. My session file contains: [GNOME Session] Name=i3 Gnome session

Bug#701912: tig: Failed to chdir: No such file or directory when used inside submodule

On Fri, Mar 01, 2013 at 10:17:06AM +0100, Sebastian Harl wrote: On Thu, Feb 28, 2013 at 05:10:57PM +, Mike Crowe wrote: tig reports errors like: tig: Failed to chdir(../../submodule-directory): No such file or directory when started inside a submodule that has been created

Bug#701912: tig: Failed to chdir: No such file or directory when used inside submodule

Package: tig Version: 1.0-2 Severity: normal tig reports errors like: tig: Failed to chdir(../../submodule-directory): No such file or directory when started inside a submodule that has been created by the version of git in Wheezy (1:1.7.10.4-1+wheezy1) It looks like this problem has been

Bug#701912: Patch tested

I've tested the upstream patch linked from https://github.com/jonas/tig/issues/54 and it solved the problem for me. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#689712: faad crashes when given ADTS AAC file with large ID3v2 tag

Package: faad Version: 2.7-8 Severity: normal Tags: upstream I have an ADTS AAC file with an ID3v2 tag containing an image. Attempting to skip this header by passing a value larger than the buffer size to advance_buffer causes fill_buffer to misbehave. The problem is detected in free() during a

Bug#689712: Improved patch

Here's a version of the patch with the asserts removed so it actually compiles. Mike.--- faad2-2.7.stock/frontend/main.c 2008-09-22 18:55:09.0 +0100 +++ faad2-2.7/frontend/main.c 2012-10-05 13:59:19.699009140 +0100 @@ -130,11 +130,18 @@ static int fill_buffer(aac_buffer *b) static void

Bug#687412: icedove: Tooltip remains visible for too long and overlays attachment filename entry box when using gnome3

Package: icedove Version: 10.0.6-2 Severity: normal Steps to reproduce on Wheezy: 1. Ensure that Gnome3 is configured to attach modal dialogs. 2. Ensure that Icedove is maximised. 3. Click on Write button to start a new email. 4. Click on Attach button to add an attachment. 5. Notice that

Bug#674497: Bug #674497: after searching in gnome-shell overview gjs-console is consuming 100% CPU

Having just upgraded to Wheezy I'm also seeing gjs-console consume 100% CPU for around thirty seconds after searching (and then cancelling) in the gnome-shell overview. Here is the output that was requested by Michael Biebl back in May: chuckie:~ cat /proc/`pidof gjs-console`/cmdline|tr '\0'

Bug#506239: SEGV in multithreaded program causes incorrect valgrind exit code

I've tested using: valgrind 1:3.6.0~svn11254+nmu1 (from squeeze) valgrind 1:3.7.0-5 (from sid) Both yield an exit code of 137 rather rather than the requested 42 (which appears to disagree with the man page) but I don't really care as long as it doesn't yield zero. The original problem no

Bug#659351: minicom: Minicom stops receiving in -R utf-8 mode

Package: minicom Version: 2.4-3 Severity: normal LANG=en_GB.utf8 Minicom parameters -m -c on -8 -R utf-8 If minicom receives an invalid UTF-8 sequence from the serial port it doesn't display any more of the characters that have been sent. For example (borrowing from bug 413934) if the byte

Bug#623479: bash-completion: p4 completion yields bash: _get_comp_words_by_ref(): `preprev': unknown argument

On Wed, 20 Apr 2011 16:43:48 +0100, Mike Crowe wrote: With the Perforce command line client p4 and bash-completion installed if I type: p4 edit TAB I get the following error: bash: _get_comp_words_by_ref(): `preprev': unknown argument It appears that this has been fixed in http

Bug#623479: bash-completion: p4 completion yields bash: _get_comp_words_by_ref(): `preprev': unknown argument

Package: bash-completion Version: 1:1.2-3 Severity: normal With the Perforce command line client p4 and bash-completion installed if I type: p4 edit TAB I get the following error: bash: _get_comp_words_by_ref(): `preprev': unknown argument It appears that this has been fixed in

Bug#414569: Confusion

I think that there are separate problems here that are getting intermingled in this bug report and others (e.g. https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/94940 ) The particular variant that the original bug reporter appears to be suffering from (and I happen to also be suffering from)

Bug#413934: Bug appears to be fixed in squeeze glibc

I've tested minicom in a squeeze chroot using the byte sequence I provided earlier. I could not reproduce the problem. Minicom displays a strange character (as would be expected) but does not assert. I tested with: ii libc6 2.11.2-2

Bug#517716: Acknowledgement (linux-image-2.6.26-1-686: ehci_hcd 0000:00:02.2: HC died; cleaning up when importing photographs via PTP using gthumb)

Unfortunately the motherboard that I saw this problem on died. :( I tried to reproduce it on my new Intel motherboard using linux-image-2.6.26-2-686 v2.6.26-24 but could not do so. Thanks. Mike. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of

Bug#548042: libc6-i386: Test program using iconv crashes on exit in __libc_freeres

Package: libc6-i386 Version: 2.7-18 Severity: normal Compile the attached test program on lenny-amd64 with -m32 and run the generated binary. It segfaults inside __libc_freeres: #0 0xf7ec513f in free_derivation () from /lib32/libc.so.6 #1 0xf7e82cc0 in tdestroy () from /lib32/libc.so.6 #2

Bug#517716: Acknowledgement (linux-image-2.6.26-1-686: ehci_hcd 0000:00:02.2: HC died; cleaning up when importing photographs via PTP using gthumb)

Further to my original report I've done some more experiments and noted that: - The problem does indeed seem to be file size related. Small images and video files do not cause the host controller to die. A transfer of four video files totalling over 700MiB did cause the failure. - The system

Bug#517716: linux-image-2.6.26-1-686: ehci_hcd 0000:00:02.2: HC died; cleaning up when importing photographs via PTP using gthumb

Package: linux-image-2.6.26-1-686 Version: 2.6.26-13 Severity: normal When downloading pictures from one of my PTP cameras my USB host controller appears to die. Pictures that have been successfully transferred are not deleted from the camera. The ports connected to that controller don't work

Bug#517730: gthumb: Failed PTP import fails to show any error message

Package: gthumb Version: 3:2.10.8-1 Severity: normal Importing a large movie file from my camera fails due to bug 517716. Unfortunately gthumb doesn't show any user-visible error in this situation, it just switches to a window showing the photos and videos that it has downloaded. It also doesn't

Bug#506239: SEGV in multithreaded program causes incorrect valgrind exit code

Package: valgrind Version: 1:3.2.1-1 Severity: normal -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.24-etchnhalf.1-686-bigmem Locale: LANG=en_GB.UTF-8,

Bug#506239: valgrind output

Here is the output from valgrind-3.2.1. The output from 3.3.1 is similar. Notice the shell-prompt in the middle and the exit code at the end. repton:~/src/valgrind-bugs valgrind --error-exitcode=42 vgt ==10322== Memcheck, a memory error detector. ==10322== Copyright (C) 2002-2006, and GNU GPL'd,

Bug#413934: minicom crashes if LANG=de_DE.UTF-8 is set - with LANG=POSIX it works fine

Hi Adam Markus, I think I may have found a recipe for reproducing the minicom assert with LANG=en_GB.UTF-8. As Markus reported the problem goes away with LANG=posix. Arrange for Minicom receive the following (invalid UTF-8) byte sequence over the serial port: f8 e2 82 ac c2 a3 0a The error

Bug#350183: this isn't limited to network devices

On Feb 14, Mike Crowe [EMAIL PROTECTED] wrote: This means that on some boots the boot disk on megaraid is sda and on others it's sdb. On Tue, Feb 14, 2006 at 10:12:09PM +0100, Marco d'Itri wrote: It will happen among devices handled by different drivers. The solution is to use the /dev/disk

Bug#350183: this isn't limited to network devices

On Feb 14, Mike Crowe [EMAIL PROTECTED] wrote: I don't think this issue is limited to network devices. On Tue, Feb 14, 2006 at 01:46:30PM +0100, Marco d'Itri wrote: You are showing some totally unrelated issue which is obviously a bug in lvm2. I admit that the log excerpt I provided

Bug#350183: Bug #350183: this isn't limited to network devices

K8 SMP machines ii udev 0.081-0bpo1 /dev/ and hotplug management daemon -- Mike Crowe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#349861: sound-juicer: Silently creates zero length files if disk is full.

Package: sound-juicer Version: 2.12.3-3 Severity: normal I didn't have much disk space free when ripping a CD to flac using Sound Juicer. Sometime during the process the disk filled up (sans the reserved for superuser part) and the file that was being written at the time was truncated. The

Bug#349012: podracer: Cryptic curl error if subscriptions file contains blank lines.

Package: podracer Version: 1.3-1 Severity: normal Tags: patch It is quite easy to get blank lines at the end of a subscriptions file and the error message given by podracer in this situation is not good: curl: no URL specified! curl: try 'curl --help' or 'curl --manual' for more information It