Package: rrdtool Version: 1.7.2-4.2+b5 Severity: normal The conversion to 64 bit time_t causes rrd files created on an armhf system to be misparsed by javascriptrrd. That is a library, not included in debian, which contains its own rrd parser. It handled armhf rrd files fine before debian made this change, because they were in the same format as i386 rrd files, which it supports.
Debian has essentially and accidentially made up its own rrd file format
variant for 32 bit systems with 64 bit timestamps. Every third-party rrd
parser will need to be fixed to deal with it.
That seems like a lot of work, when Debian could have just made the 32 bit rrd
file format identical to the 64 bit rrd file format. I feel it is not too late
to revisit this decision. If it is not revisited, rrd interoperability with
other tools is probably dead for armhf & etc.
I doubt I will be able to get in touch with the javascriptrrd developer
to get it to support this, and also it's not entirely clear to me how it
should even detect the debian format[1]. So I guess I'll just drop this
patch to it here, which at least makes it work with these files, though
breaks support for i386 and amd64 rrd files.
--- a/javascriptrrd/src/lib/javascriptrrd.wlibs.js
+++ b/javascriptrrd/src/lib/javascriptrrd.wlibs.js
@@ -555,7 +555,7 @@ RRDHeader.prototype.calc_idxs = function() {
this.live_head_idx=this.rra_def_idx+this.rra_def_el_size*this.rra_cnt;
// time_t last_up, int last_up_usec
- this.live_head_size=2*this.int_width;
+ this.live_head_size=4*this.int_width;
this.pdp_prep_idx=this.live_head_idx+this.live_head_size;
// char last_ds[30], unival scratch[10]
[1] It would probably need to probe for something that looks like
pdp_prep at two different offsets, to detect if live_head used 64 bit time_t
or not. Since pdp_prep.last_ds is ASCII, it could look for ascii padded out
to 30 bytes with NUL.
--
see shy jo
signature.asc
Description: PGP signature
