Sorry for the delay in replying to your report.
No problem.
Actually, I am unable to reproduce this on a Testing or Unstable
installation.
I did however reproduce it when installing the unstable package of
iptotal on a Stable release of Debian, as it seems you did too (this
is not necessarily a good practice, you should build a backport or ask
for someone to do it for you [1]).
Thanks for that. I've had success installing packages from unstable
directly before, but I guess I hit a snag this time.
It actually looks like the bug comes from rrdcgi rather than iptotal.
In the cgi scripts, you will find that the specified path for the
images is:
------------8<------------------------8<------------
--imginfo '<IMG SRC=/iptotal/images/%s ALT="kbyte(s)">'
------------8<------------------------8<------------
where "%s" stands for the filename part of the graph generated. This
however, should not include the path of the file (so says the man file
of rrdcgi).
i.e. instead of replacing '%s' with
/var/lib/iptotal/images/eth_week.png, it should be replaced with
eth_week.png.
In the Testing and Unstable installations, '%s' is being replaced with
its right value.
That's exactly it. Since it's in rrdcgi, it looks like you can close
this bug against iptotal. My apologies.
Unfortunately, I'm not sure of the best way to fix this in the cgi.
The images do get generated, and I can view them by inserting my own
<img> links in the template.html document, but they don't show up on
the various cgi pages.
The way I see it, this can be corrected by replacing, in the cgi
files, '%s' with the actual filename of the generated png, instead of
relying on rrdcgi to do it.
I will fix this in the next release.
That said, since rrdcgi gives the correct result in the unstable
version, you are probably best off leaving iptotal as is. And since
the problem is fixed in the unstable rrdcgi, it looks like no bug
should be filed there.
I'm sorry for the mess up.
As the unstable is not meant to be installed on a stable distribution,
and as this in unreproducible on a testing/sid installation, I will
lower the severity to important.
That makes perfect sense. Sorry about that.
Thanks for the follow-up!
John
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org