Bug#508613: more info

By the way, the manual claims to support this kind of operation: "Copies between two remote hosts are also permitted." It appears from the -v output that the way it tries to process scp host1:file1 host2:file2 is to ssh to host1 and execute this there: scp file1 host2:file2 Indeed, if h

Bug#538891: bash: completion incorrect with symlinks

Package: bash Version: 3.2-4 Severity: normal pet...@naxos:~/tmp$ mkdir foo pet...@naxos:~/tmp$ mkdir bar pet...@naxos:~/tmp$ cd bar pet...@naxos:~/tmp/bar$ mkdir baz pet...@naxos:~/tmp/bar$ ln -s ../foo foo pet...@naxos:~/tmp/bar$ cd foo pet...@naxos:~/tmp/bar/foo$ ls ../ba Hit Tab, completes

Bug#289479: cdrecord: more serious => can cause apparent write error

Package: cdrecord Version: 4:2.01+01a01-2 Followup-For: Bug #289479 if the same file is specified more than once, *and* there's a file specified after the second occurance, the burn process bombs out, like so: [EMAIL PROTECTED] cdrecord dev=ATAPI:/dev/cdrom fs=12m speed=24 -dummy -sao -pad \ -a

Bug#137311: aptitude: suspend, resume also inhibits user input to dpkg

Package: aptitude Version: 0.2.15.8-1 Followup-For: Bug #137311 i experience the same bug as Mr. Hess, but i've also observed that if dpkg asks for input after resuming, it doesn't work unless i do an `stty sane < /dev/pts/` from another terminal. (i also did a `reset 2> /dev/pts/` to fix the loo