Modifikationen an eibd und rrdtool upstream?

[henfri]

Hallo,

ich versuche gerade die CV unter Ubuntu 64bit zu installieren.
Daher komme ich mit den Paketen von repo.wiregate.de nicht weiter.

Jetzt frage ich mich, ob die Modifikationen

*** Important note on diagram-backend ***
It uses a modified version of rrdtool, adding a "fetchj" option.
You can find source and Debian-packages here:
Index of /wiregate/pool/main/r
Index of /wiregate/pool/main/libr

*** Notes on the KNX-backend ***
The KNX-backend uses
/usr/lib/cgi-bin/l : a dummy-login
/usr/lib/cgi-bin/r : a symlink to /usr/bin/eibread-cgi
/usr/lib/cgi-bin/w : a symlink to /usr/bin/eibwrite-cgi
eibread/write-cgi are part of a modified eibd-clients package here:
Index of /wiregate/pool/main/e
(source: bcusdk)

schon upstream angelangt sind?

Wenn nicht: Kann mir jemand sagen, wie ich die Pakete für Ubuntu (12.04) installiere/baue?

Ich hab's schon versucht (apt-get -b source ...), bin aber gescheitert.
Ich gehe es morgen nochmal Schritt für Schritt durch und poste den Fehler, aber vielleicht hat jemand ja eine Mitschrift seiner Installation.

Gruß,
Hendrik

[makki]

Also ich antworte nun nicht aus Liebe sondern aus trotz:
Dafür das es diese IMHO essentiellen Dinge nicht Upstream geschafft haben kann ich wenn - nur peripher was, es war nicht so das ich es nicht versucht hätte..

Das liegt da alles! 100%!
Also würden böse Zungen es evtl. einen Fork nennen (sehe ich aber nicht so, weil ich alles davon auch sehr zeitnah upstream geschickt habe), man muss halt ein bisserl wissen wie die chose funktioniert.. Also wo soll ich jetzt anfangen? bei automake? bei make? bei dpkg-buildpackage?

Also gut, es ist einfacher, ziehen wir das am Beispiel von rrdtool aufm Ubuntu 12.10/64 (for what?) mal durch (ohne dich mit apt/sources.list zu langweilen, damit gings noch 5 Zeilen kürzer):

cd 
mkdir bastelwastel
cd bastelwastel
wget http://repo.wiregate.de/wiregate/pool/main/r/rrdtool_1.3.1-4+nmu2.dsc
wget http://repo.wiregate.de/wiregate/pool/main/r/rrdtool_1.3.1-4+nmu2.diff.gz
wget http://repo.wiregate.de/wiregate/pool/main/r/rrdtool_1.3.1-4+nmu2_i386.changes
wget http://repo.wiregate.de/wiregate/pool/main/r/rrdtool_1.3.1.orig.tar.gz
sudo apt-get build-dep rrdtool
dpkg-source -x rrdtool*dsc
cd rrdtool*
dpkg-buildpackage
sudo dpkg -i ../rrd*.deb

Soweit die Theorie, ich habs grad ausprobiert, es scheitert an Ruby1.9 (was damit ungefähr soviel zu tun hat wie fahrradfahren mit fliegen..)
-> Das hättest Du allerdings auch bereits herausarbeiten können?

Also, ich sch** auf Ruby, da kann ich nix für das der überflüssige Käse da als Build-depend drinsteht -> bitte Uptream nen Bug aufmachen, warum das rrdtool zwingend [überhaupt] Ruby benötigt! (sowas gehört IMHO optional, geht auch..)
Dann patchen die Debian-Jungs natürlich noch fröhlich am ruby rum (ich frage mich immernoch: praxisrelevanz?)
Dann löscht ma den ganzen Ruby-python-krampf aus debian/control , rules quilt usw raus, fertig, geht

-> Jetzt wäre der richtige Zeitpunkt, dem Package-Maintainer seinen Missmut darüber mitzuteilen, warum man ein pures C-Programm nicht ganz ohne den überflüssigen Ruby-Mist erstellen kann
Ehrlich, mir ist das wurscht, ich bekomms ja gelöst - weil die Diskussion ist auf der -devel Liste müssig, wenn nicht mindestens 100 "reinhauen" und den 3 ruby-freaks die klappe stopfen.. So ist OSS

Makki

P.S.: Beim eibd und owfs funktioniert dieselbe Methode mit weniger Stolperfallen.. Aber das sind mittlwerweile auch fast forks (beim eibd eine Zeile, beim owfs dutzende)
Das sind aber alles nach bestem Wissen&Gewissen saubere Debian-packerl inkl. source, ich kann nur nicht für alle alle Sünden der Vorgänger geradestehen..
(es nervt mich übrigens auch tierisch, das ich - ohne jegliche Not! bei den meisten Paketen was an debian/control drehen muss damit diese dann (5.0) problemlos auf Ubuntu 12.10 gebaut werden können oder umgekehrt..)
Aber das gehört wohl zum guten Ton, vielleicht ein Intelligenztest?, ich habe mich darüber schon mehrfach beschwert, hilft aber nur wenn andere das auch tun..

Makki

[greentux]

Upstream ists ja gekommen. Nicht unbedingt als fetchj (neue Funktion), sondern als Anpassung von xport (neben xml nun auch json):

rrdtool xport --json

Ich weiss, 1.3.1 hat so seine Vorteile auf dem WG. Aber was spricht dagegen, die CV das mit xport machen zu lassen, statt fetchj?
xport könntest Du ja in 1.3.x reinpatchen. Auf neueren Plattformen wäre kein Patch notwendig.

[henfri]

Hallo,

danke für eure Unterstützung.

Aber ich fürchte, das wird nix.
Ich habe in der "control" alle Verweise auf ruby entfernt. Auch das Verzeichnis bindings/ruby habe ich entfernt, nachdem er darin auch wieder über ein fehlendes ruby1.9 gemeckert hat.

Jetzt meckert er darüber das bindings/ruby fehlt.

Makki, ich weiss du gibst dein Bestes, aber so ist es für einen nicht Profi (und nicht nur für einen Laien) kaum möglich, die CV zu nutzen.

Wäre es möglich, den Vorschlag von greentux umzusetzen?

Denn selbst wenn ich das jetzt mit deiner Hilfe hinbekomme: Der nächste will die CV unter Suse verwenden und dann steht der da. Oder die Software xyz will rrdtool mit ruby verwenden. Und dann stehe ich da.

Zum eibd geht's hier weiter:
https://knx-user-forum.de/knx-eib-fo...tml#post278329

[Mir geht's hier nicht (nur ;-) um mich: Bei mir läuft die CV auf einem CG. Aber die CV soll doch einem breiterem Publikum zugänglich sein als den Wiregate Kunden, oder?]

Gruß,
Hendrik

[henfri]

Nachdem jetzt "nebenan" der Eibd [für mich] soweit abgekaspert ist, fehlt noch das RRD-Tool.

Wäre es denkbar den Vorschlag von Greentux umzusetzen?

Davon abgesehen wäre es echt gut, wenn eibread/write-cgi als Teil der CV bereitgestellt würde. Da wäre man zwei wichtige Abhängikeiten (eibd-und rrdtool- Version) los.

Gruß,
Hendrik

[Chris M.]

Davon abgesehen wäre es echt gut, wenn eibread/write-cgi als Teil der CV bereitgestellt würde. Da wäre man zwei wichtige Abhängikeiten (eibd-und rrdtool- Version) los.

Was meinst Du damit?

Das Repository nach Open Automation (also dort wo auch die CV liegt) ändern? Gerne.

Die Dateien mit der CV ausliefern? Macht nicht viel Sinn, da gänzlich anderer Scope

Die Dateien als Abhängigkeit für das Debian-Paket definieren, so dass die bei einem Anwender automatisch mit installiert werden? Ist seit Anfang an umgesetzt.

Die Abhängigkeit zum eibd und rrdtool lösen? Geht nicht, die Dateien hier legen nur eine dünne Schicht auf's andere drauf, das ist hier essentiell.

Die "richtigste" Lösung wäre aber das CV-Backend in das eibd bzw. rrdtool Repository zu bringen. Wurde aber dort nicht wirklich als wichtig erachtet...

[greentux]

Sehe ich nicht ganz so Chris. Weil, was soll die große Welt im eibd mit den reads/writes.
Meiner Meinung nach gehört das in ein cv_eibd Paket?
Ggf. kommen ja mal weitere Konnektoren dazu.
Ich kann mich da drum kümmern. So, wie es im Moment ist, ist nur fürs WG so richtig brauchbar, wie man ja hier sieht.

Auf einem Non-WG kann man die read/write ja auch in Python und PHP realisieren denke ich.

[Chris M.]

Klar, ein eigenes Paket wäre auch eine Lösung, und tatsächlich wohl die sauberste. (Hm, ist es nicht sogar aktuell ein eigenes Paket).

Das CV Backend kann in beliebigen Sprachen geschrieben sein und auf beliebige Quellen zugreifen, eibread-cgi und eibwrite-cgi ist nur eine von vielen Möglichkeiten (wenn auch eine ganz prominente...; ich selber hab da schon einige Variationen durch)

Die werden aber auch in der Zukunft wohl durch was deutlich anderes abgelöst werden. Aber bis dahin kann man entweder so weiterleben (geht ja schon einige Zeit so), oder das natürlich auch noch etwas perfektionieren.

[greentux]

Mmmh, grad hat ich mich fast dazu entschlossen, mich mal mit dem Packaging für Ubuntu und Co zu beschäftigen
Aber nun, was wird da in Zukunft anders werden Chris?

[Chris M.]

Mmmh, grad hat ich mich fast dazu entschlossen, mich mal mit dem Packaging für Ubuntu und Co zu beschäftigen

Ist sicher nicht verkehrt.

Aber nun, was wird da in Zukunft anders werden Chris?

Wer die Commit-Logs liest, weiß es. Wer nicht, gehört (noch) nicht zum Zielpublikum.

[henfri]

Hallo,

@Chris:
ich erwarte kein *.deb, *.rpm, ... für die ganze CV

Aber ich erwarte auch keine "DLL-Hell".

Vielleicht stelle ich mich tatsächlich überaus dusselig an, aber ich halte die Anforderungen an einen gepatchten eibd* und rrdtool für sehr ungünstig.

Das habe ich bisher als unvermeidlich angesehen, habe jetzt aber gelernt, dass es mitnichten so ist.

Eine Lösung für rrdtool hat greentux ja oben aufgezeigt. Kannst du dazu etwas sagen? Wie hoch wäre der Aufwand/wärst du bereit, dich damit zu beschäftigen?


Zum Eibd: * Der muss ja gernicht gepatcht werden, sondern man braucht einfach die Tools eibread-cgi und eibwrite-cgi. Und wie ich es verstanden habe, könnte man die einfach mit der CV mitliefern. Dann noch ein Readme mit Instruktionen zum Kompilieren dieser zwei (mini)-Tools und 95% der Probleme (eibd selbst kompilieren mit Abhängikeiten, Inkompatibilitäten etc etc.) fiele weg.

Ein kleiner Schritt für die CV, ein großer für den Nutzerkreis, oder?

Gruß,
Hendrik

[Chris M.]

Rum rrdtool kann ich nichts sagen, mit dem habe ich mich nie beschäftigt.

Der eibd braucht kein Patch und eine "DLL-Hell" gibt's da in keinster Weise. Wahrscheinlich funktioniert eibread-cgi/eibwrite-cgi auch noch mit einem eibd-0.0.4 oder älter...

Einfach mitliefern mit der CV ist nicht. Die CV sind statische Dateien, die ein Web-Server ausliefert - egal auf was und wie der läuft.
eibread-cgi und eibwrite-cgi sind dagegen Programme, die für eine Zielplattform kompiliert werden muss: 32 oder 64 bit? x86, ARM, Sparc, MIPS, PowerPC, ...? Linux? Windows? OpenBSD? ... - alles eigene Kompilate. Sollen die alle mit der CV mit kommen?!?

Und jetzt kommts noch härter: eibread-cgi und eibwrite-cgi sind gerade mal eine mögliche Implementierung des Backends für eine Umgebung. Aber auch openHAB geht inzwischen als Backend - soll ich das nun auch noch mitliefern?!?

Nein, das wird nichts. Das macht keinen Sinn.

Wenn, dann muss eibread-cgi/eibwrite-cgi als eigenes Paket verteilt werden.

[greentux]

Naja Chris, also es gibt garantiert mehr Leute, die eibd nutzen als Leute, die CV nutzen. Von daher denke ich, das die Backends doch eher zur CV gehören, auch wenn Du Dich selber primär mit dem Frontend beschäftigst, oder?
Wie gesagt, gehen die read und write auch als php/python und damit sind wir die Architektur schon ein wenig los... Das rrdfetch ist nur ein Script. Mehr brauchts eigentlich nicht.
Ich denke ein Paket für die CV und eines für nen jeweiligen Konnektor.

Die Logikengine die Du meinst, ist dann sicher ein weiteres Paket...

[Chris M.]

Klar, ein eigenes Paket wäre auch eine Lösung, und tatsächlich wohl die sauberste. (Hm, ist es nicht sogar aktuell ein eigenes Paket).

.....

[henfri]

Rum rrdtool kann ich nichts sagen, mit dem habe ich mich nie beschäftigt.

Wer wäre den ein guter Ansprechpartner?

Der eibd braucht kein Patch und eine "DLL-Hell" gibt's da in keinster Weise. Wahrscheinlich funktioniert eibread-cgi/eibwrite-cgi auch noch mit einem eibd-0.0.4 oder älter...

Na, das Problem hatte ich mit rrdtool, das stimmt.

Einfach mitliefern mit der CV ist nicht. Die CV sind statische Dateien, die ein Web-Server ausliefert - egal auf was und wie der läuft.
eibread-cgi und eibwrite-cgi sind dagegen Programme, die für eine Zielplattform kompiliert werden muss: 32 oder 64 bit? x86, ARM, Sparc, MIPS, PowerPC, ...? Linux? Windows? OpenBSD? ... - alles eigene Kompilate. Sollen die alle mit der CV mit kommen?!?

Nein, wie hatte ich ja bereits oben gesagt: als Source mit Instruktionen zum Kompilieren. Aber eben einzig eibread-cgi&co.

Das Zitat ganz oben in meinem Eingangspost ("eibread/write-cgi are part of a modified eibd-clients package here:") suggeriert(e) mir, dass ich eben den eibd aus diesem Repo nutzen muss.

Und jetzt kommts noch härter: eibread-cgi und eibwrite-cgi sind gerade mal eine mögliche Implementierung des Backends für eine Umgebung.

Na komm. Der User möchte doch einfach nur die CV nutzen. Viele werden den eibd haben oder per Paket installieren können für ihre Distribution mit allen Abhängigkeiten usw usw.

Wenn jetzt noch die obigen *.c files inklusive Makefile oder ähnlichem geliefert würden, könnte der arme Dau mit einem make oder ./configure &&make&& make install diese mini-Programme installieren und könnte so ohne weiteres/mit sehr kleinem Aufwand ein Backend erstellen.

Wenn, dann muss eibread-cgi/eibwrite-cgi als eigenes Paket verteilt werden.

Für 32 oder 64 bit? x86, ARM, Sparc, MIPS, PowerPC, ...? Linux? Windows? OpenBSD? ... Für Suse, Für Debian, ... ...

Ich verstehe echt nicht, was einem Verzeichniss "Backend" mit den *.c, Makefile und co schlimm wäre

Gruß,
Hendrik