Modifikationen an eibd und rrdtool upstream?

[makki]

eibd-clients geht echt einfacher, mein Packerl lässt sich von OpenWRT über Dreambox bis Ubuntu 12.10/64 Warnungs-frei bauen (und entspricht v0.0.5, ich hab das absichtlich darunter gehalten, damit es keine Konflikte gibt!).. Wenn mans lieber gern auf die harte Tour mit Makefile-patchen hat, ok, kann man das .changes nehmen

Beim rrdtool ists wesentlich komplizierter.. Aber jetzt mal ehrlich, mir liegt nunmal primär an der Performance&Funktion in der CV, ebenso wie "Upstream" das wurscht ist, ist es mir wurscht ob das mit Fedora 199.77 perfekt ist
Natürlich kann man das hinbiegen aber - mal böse gesagt - mich bezahlt niemand für, also soll sich doch bitte jemand drum kümmern, dem daran liegt, das es unter Susie 17 mit rrdtool 1.4 und libcairo geht (der overhead ist da wurscht, ist eh Faktor 10+) - und einfach nen Wrapper oder nen patch für fetchj schreiben (das sind keine 5 Zeilen unterschied!), fertig, oder?

Makki

[greentux]

henfri, in aller Kürze

- hole die die pthsem, ./configure; make; make install
- hole Dir das aktuelle bcusdk-0.0.5
- kopiere dir aus dem eibd-client-source paket die zwei files
- passe das Makefile.am noch an (die letzten beiden Einträge)
- anschliessend ins bcusdk-0.0.5 Verzeichnis wechseln und

ACLOCAL='aclocal -I /root/pthsem-2.0.8' autoreconf -i -v -f

aufrufen. Ggf. fehlen Dir ein paar Sachen:
- libxml2-dev
- libtool
- autoconf
fehlende Sachen installieren.
Anschliessend ein

./configure --without-pth-test --enable-onlyeibd
make
make install

Und alles sollte übersetzt sein.

Mit dem rrdfetch bin ich noch nicht weiter, da das JSON aus dem fetchj anders aussieht als das JSON aus dem xport.

[ctr]

Im upstream eibd-clients sind die Tools NICHT drin. Nur im WG spezifischen eibd-clients...

Eben drum! Deswegen gehören sie (imho) auch nicht rein...

[henfri]

Hallo,

erstmal freue ich mich, dass ihr hier nach einer Lösung sucht. Wäre klasse, wenn das in Zukunft (Release?) einfacher wird.

henfri, kannst du mir ggf. mal ein rrd hier anhängen, was unter 64 bit erzeugt wurde?

Siehe Anhang.

Das soll die Anwort sein henfri?

Sorry, das war eine Kopie aus dem Firebug und im Editor-Fenster sah es noch vernünftig aus.

Was macht der ganze Squeezeboxkram da?

Das sind -glaube ich- die Cookies, die zu dem Zeitpunkt auf dem Rechner waren.

Gruß,
Hendrik

[greentux]

Im upstream eibd-clients sind die Tools NICHT drin. Nur im WG spezifischen eibd-clients...

[ctr]

Auf meinem WG sind die im eibd-clients Paket mit drin.

Genau, aber eibd-clients ist ein kein WG oder Comet-spezifisches Paket sondern kommt von Upstream:

Maintainer: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Source: bcusdk
Description: eibd clients  Simple example programs to perform management tasks on a EIB system.
Homepage: http://www.auto.tuwien.ac.at/~mkoegler/index.php/bcusdk

Ich verstehe nicht, warum das (eibread/write) "example programs" und dann noch im Upstream Paket sein sollten...
Sauberer wäre (wie auch von Chris vorgeschlagen, wenn ich ihn richtig verstanden habe) diese in ein eigenes Paket auszulagern, z.B. "cometvisu-eib-backend" oder hält es irgendjemand für realistisch, dass diese Pakete in das Upstream Paket einziehen?

Wenn ich die Debian-Philosophie richtig verstehe, dann sollte nicht per Patch eine zusätzliche Funktionalität in ein Paket kommen (jedenfalls nicht dauerhaft), sondern entweder temporär zusätzliche Funktionalität (mit Erwartung einer Implementation Upstream) oder Build-Fixes (z.B. wenn Debian-spezifisch und auch temporär oder wenn dauerhaft wenn von Upstream abgelehnt).

Gruß,
Christian

[greentux]

Und jedes übertragene Byte und jede aktive Millisekunde hält die Antennen eines Mobil-Gerätes wach und belastet somit die Batterie.

Mmmh, dann musste mal bei IOS und Android viel tiefer anfangen. Das wird sicher nicht an 50% mehr Bytes in der CV liegen...
Aber ich schaus mir an.
Vl. ist die Schnittmenge der Leute die CV auf non-WG haben wollen UND nicht Unmengen an Diagrammen auf der STartseite brauchen größer als gedacht.

[Chris M.]

Was sagt das Diagramplugin, wenns das json mit Metadaten bekommt?
[...]
Chris, vl. weißt Du das auch.

Kann ich nicht (auswendig) sagen, mit dem Diagramm-Plugin hatte ich mich nur ganz selten und am Rande beschäftigt. Das kam von Netzkind, glaube ich.

"Delayed diagram loading" steht ja eh noch auf der Wunschliste. Das würde dann auch helfen.

Das mag ein einigen (den meisten?) Fällen helfen - ist aber keine Lösung für das Problem:

Jemand der die CV für reines Monitoring einsetzt, mag durchaus auf der Start-Seite zig Diagramme haben.

Und jedes übertragene Byte und jede aktive Millisekunde hält die Antennen eines Mobil-Gerätes wach und belastet somit die Batterie.

[greentux]

Makki, das fetchj liefert das json ja etwas "nackt" aus. Da Du die andere Seite kennst. Was sagt das Diagramplugin, wenns das json mit Metadaten bekommt?
Also in etwa so:

{ about: 'RRDtool xport JSON output',   meta: {     start: 1333111500,     step: 10,     end: 1333111500,     legend: [       ''           ]      },   data: [     [ 8.7720000000e+00 ],     [ 9.0620000000e+00 ],     [ 9.0540000000e+00 ],     [ 8.9620000000e+00 ],

Chris, vl. weißt Du das auch.
Ja zur Mailingliste geh ich nochmal. Aber vorher will ich selber sehen, wie groß der Geschwindigkeitsunterschied ist. Aus vielen Diskussionen auf der LKML weiss ich, wie schwer es ist "Sonderlocke mit minimalem Vorteil" gegen "geht schon, nur nicht ganz so schön" durchzubringen.
Insofern müsste ich mal eine CV bauen, die 8 Diagramme mit xport anzeigt und schauen, wie das aussieht.
"Delayed diagram loading" steht ja eh noch auf der Wunschliste. Das würde dann auch helfen.

[Chris M.]

Markus, dann bring halt das Thema auf der Mailingliste nochmal auf und box es durch - hat jeder was von und Du musst nicht mal programmieren können

[greentux]

Das es fetchj gibt, ist ja nicht das Problem. Nur das WIE ist hier das Problem. Es wurde auf der Mailingliste keine Lösung gefunden, die allen passt. Sowas kostet natürlich Zeit und Argumente. Das ist mir bewusst.
Nur ist jetzt das Problem, das das auf genau den einen Einsatzfall passt.

Klar, es kann jetzt jeder sein rrdfetch bauen. Ich versuchs die Tage aber nochmal mit nem xport.

[makki]

Wieso vergisst Du nicht das xport und verwendest nur das fetch und jsonised das dann? Das wird doch von der CV erwartet, oder?

In eine höherwertigen Scriptsprache ein Dreizeiler ;-)

Eben: das geht wunderbar, gibts in irgendeinem Post von mir hier sogar ein Bash-script dazu (glaub ich) - aber das war halt A***-langsam, deswegen gibts fetchj

Makki

[greentux]

Weil Scriptsprache wieder Scriptsprache
Dauerts ja noch länger... oder?
Ausserdem kann ich gut und gerne man-pages lesen und Scripte anpassen, aber kein Python oder Co.

[callidomus]

Alles zurück henfri. Das xport ist wesentlich mächtiger als das fetch. Das wird heute Abend nix mehr...

Wieso vergisst Du nicht das xport und verwendest nur das fetch und jsonised das dann? Das wird doch von der CV erwartet, oder?

In eine höherwertigen Scriptsprache ein Dreizeiler ;-)

[greentux]

henfri, kannst du mir ggf. mal ein rrd hier anhängen, was unter 64 bit erzeugt wurde?