Modifikationen an eibd und rrdtool upstream?

[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]

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.

[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]

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.]

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]

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.

[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]

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

[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

[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...

[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.

[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

[henfri]

Hallo,

die CV funktioniert jetzt soweit, hinsichtlich der Kommunikation mit dem Bus bei mir.
[ACHTUNG]Aber es geht ja nicht um mich![/ACHTUNG]

Ich möchte, dass es für den geneigten User einfach ist, die CV zu installieren. Und das ist es NICHT.

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

Wunderbar. Wäre es dann nicht sinnvoll, den für die CV nötigen Teil davon bei der CV mitzuliefern? Einmal als Quelltext mit Build-Instruktionen, einmal als x86-Deb (weil vorhanden), meinetwegen auch als amd-64-Deb und schlieslich als deb-src.
Damit dürften doch wirlich 90% der User es recht einfach haben.

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?

Aber das ist doch nicht nachhaltig.
Wir predigen doch immer, dass alles was mit dem Bus zusammenhängt auch in 30 Jahren noch laufen soll. Sollen wir also 30 Jahre lang rrdtool backporten?

Da muss es doch eine bessere Lösung geben.

Gruß,
Hendrik

[ctr]

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
...

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 [...]

Ist ja schon richtig dass Du nicht dafür bezahlt wirst, dass die CV auf anderen Plattformen läuft, aber es ist nicht im Sinne von OpenSource (auch nicht Debian-konform) wenn man sowas mal eben reinpatched "weil es einfacher ist" und damit anderen quasi mutwillig das Leben schwerer macht. Natürlich "geht" es auch mit dem vorhandenen Material, aber eben nicht so wie es gedacht ist... Du beschwerst Du Dich doch selbst auch über Gefrickel bei anderen oder wenn ihnen Deine Prioritäten (z.B. Performance) nicht so wichtig sind, setzt Dich aber selbst über Standards hinweg, das passt nicht so richtig zusammen.

Versteh mich nicht falsch, dass ist als konstruktiver Vorschlag (speziell eibread/eibwrite innerhalb des eibd-clients Pakets) gemeint, die Kritik gilt nur für die Art und Weise des Umgangs damit.

Gruß,
Christian

[greentux]

Vl. geht ja schon mehr als gedacht.
Makki Du sagst, Dein eibd-client Paket könnte alles.

Wenn ich aber ein "apt-get source eibd-clients" mache, bekomme ich auch nur wieder das gesamte bcusdk geliefert. Wenns da jetzt einen "./configure --cv-clients-only" gäbe, wäre die Welt schon fast in Ordnung. Ggf. gibts das ja und ich sehe es nur nicht.
Vl. kannst Du da etwas Lich reinbringen.