It's foolish to require a bug submitter to supply an email address.
I stop here. Debian BTS is email-based, so you *need* a working email
address in order to be contacted by who needs to get your input.
Nonsense.
In principle, of course an e-mail address is not required. Followup
questions
I'm not sure if this is related or gives insight, but I should add
that the following warning appears everytime rtorrent launches:
Info hash already used by another torrent.
It seems harmless, and eventually goes away. I'm certainly not doing
anything that would cause multiple torrents to
I have now observed the same dataloss when the shutdown is
non-interactive but graceful. Specifically, I ran:
pkill -SIGINT rtorrent
from the commandline. The text during shutdown appeared to mirror
that of using control-q. Then restarted with:
rtorrent -o
This is not just a loss of the upload count.
The torrent session that just lost the upload count also lost the
file-specific priority settings. The file priority can be off,
high, or nothing. Some files were off, but were reset back to
(nothing).
--
To UNSUBSCRIBE, email to
Do you mean a shutdown and restart of the whole machine, or just
rtorrent? How do you quit rtorrent?
Sometimes I exit gracefully (control-q), and sometimes I abruptly do a
sudo shutdown -h now.
I have just confirmed that the ratio loss certainly occurs on abrupt
shutdowns. A torrent had a ratio
Not sure, why you used \RequirePackage here, I could reproduce the
problem when using \usepackage{graphicx}.
I'm not sure why I used \RequirePackage either - the original document
that broke in the etch-squeeze transation is autogenerated.
After exchanging both \usepackage commands the
After further investigation, the example usage does not conform to the
latest (apparently newly changed) syntax. That is, a -- is now
needed before addresses. So the correct command would be:
mutt -a $HOME/.bashrc -s trying to send a file -- mym...@email.com
simply sending a file
and then
Sorry Folkert, that was a typo. I meant to say the -sw 120,80
option causes the problem, but changing it to -sw 70,80 resolves the
problem. So the bug is related to size constraints.
After further experimentation, I've found that it's not reproducable
within my customized gnome-terminal
I've discovered how to reproduce this without messing with
gnome-terminal settings. Start by passing a very wide parameter to
multitail:
multitail -sw 500,10 -R 15 -l ls -R 45 -l ls
This (correctly) gives an error which indicates the width limit:
--*- multitail 5.2.2 (C) 2003-2007 by
After experimenting with all the options, I've discovered that the
segfault is related to the -sw 120,80 option. I was able to work
around the segfault by changing it to -sw 120,80.
My terminal font in the new squeeze installation seems to be bigger,
which means I have fewer characters.
It
10 matches
Mail list logo
