CCU-Repository

Alles rund ums Compilieren, Pakete erstellen etc.

Moderator: Co-Administratoren

quickmic
Beiträge: 518
Registriert: 20.01.2011, 14:39
Hat sich bedankt: 5 Mal
Danksagung erhalten: 4 Mal

CCU-Repository

Beitrag von quickmic » 10.12.2018, 13:30

Wie im Zuge vom Debuggen des HMIP-USBRF Sticks (viewtopic.php?f=56&t=47158) zum Vorschein kam, sind die Sources im occu-git (https://github.com/eq-3/occu/tree/b_3_41) nicht auf dem Stand des Codes des CCU3-Images.

Anbei eine erste Analyse des www-Teils.

Das sollten alle Entwickler im Hinterkopf behalten die Fehler suchen. Unter Umstaenden wurde bereits gefixed, aber nicht ins occu-repo eingecheckt.

Ich bin grade am ueberlegen wie man einen "echten" aktuellen Stand erstellen koennte.
Im Moment tentiere ich den www-Teil komplett von dem CCU3-Image zu nehmen.
Die java-Teile koennen auch platformunabhaengig direkt von dem Image uebernommen werden.
Die Binaries muessen zusammengesucht werden.
Um einen Dev-branch zu erstellen, wuerde ich auch die CCU3 Teile als Basis nehmen und dann die neueren Updates vom occu-Git manuell reinsyncen.

Soviel zu meinen Ueberlegungen wie man einen wirklich aktuellen Stand des Codes hinbekommen koennte.
Dateianhänge
2018-12-10 - Folder_compare_(removed_links).zip
(12.65 KiB) 112-mal heruntergeladen

Benutzeravatar
jmaus
Beiträge: 9819
Registriert: 17.02.2015, 14:45
System: Alternative CCU (auf Basis OCCU)
Wohnort: Dresden
Hat sich bedankt: 459 Mal
Danksagung erhalten: 1856 Mal
Kontaktdaten:

Re: CCU-Repository

Beitrag von jmaus » 10.12.2018, 13:40

quickmic hat geschrieben:
10.12.2018, 13:30
Ich bin grade am ueberlegen wie man einen "echten" aktuellen Stand erstellen koennte.
Im Moment tentiere ich den www-Teil komplett von dem CCU3-Image zu nehmen.
Die java-Teile koennen auch platformunabhaengig direkt von dem Image uebernommen werden.
Die Binaries muessen zusammengesucht werden.
Die einzig IMHO sinnvolle Herangehensweise ist sich einen Fork des OCCU repositories auf GitHub anzulegen und dort die Anpassungen vorzunehmen sodass man das ganze dann entweder als PullRequest an eQ3 senden kann damit diese das offizielle OCCU repository entsprechend anpassen/reparieren. Oder (und so handhabe ich das für RaspberryMatic) man pflegt diesen OCCU Fork eben mit den Anpassungen die man so festgestellt hat.

Für RaspberryMatic nutze ich wie gesagt einen eigenen Fork (siehe https://github.com/jens-maus/occu) und zusätzlich noch eine gewisse Menge von Patches gegen das OCCU repository die OCCU auf den aktuellen Stand gegenüber der CCU3 bringen (siehe https://github.com/jens-maus/RaspberryM ... Diff.patch).

Alles andere endet nur in wildem nachgepatche oder aufwendigen Anpassungen sobald eQ3 das OCCU aktualisiert bzw. wieder anpasst. Sich die Dinge einzeln aus dem CCU3 Firmware-Image zu ziehen, klingt zwar als eine nette Idee, ist es aber IMHO dauerhaft nicht.
RaspberryMatic 3.75.6.20240316 @ ProxmoxVE – ~200 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker + HomeAssistant – GitHub / Sponsors / PayPal / ☕️

quickmic
Beiträge: 518
Registriert: 20.01.2011, 14:39
Hat sich bedankt: 5 Mal
Danksagung erhalten: 4 Mal

Re: CCU-Repository

Beitrag von quickmic » 10.12.2018, 14:26

Waerst du bereit in dein bestehendes Repo die Aenderungen einzubauen? (https://github.com/jens-maus/occu)
Wie bereits erwaehnt, will ich eigentlich nicht Forken. Ausserdem ist endloses rumgeforke imho ohnehin nicht zielfuehrend. Das zersteut nur die Basis und irgendwann kennt sich keiner mehr aus.

Ich hab jetzt die Differenzen durchgeschaut. Ist granicht so schlimm wie ursprunglich angenommen. Zumindest in Bezug auf den www, Folder.

Folgende Dateien fehlen komplett in Git:
config\st_values.cgi
config\st_values.js

Folgende Files sind auf der CCU neuer:
config\easymodes\DOOR_RECEIVER\localization\de\GENERIC.txt
config\ic_common.tcl
rega\esp\side.inc
rega\pages\index.htm


Der Rest folgt spaeter.
Dateianhänge
File-Report.txt
(13.68 KiB) 113-mal heruntergeladen

Benutzeravatar
jmaus
Beiträge: 9819
Registriert: 17.02.2015, 14:45
System: Alternative CCU (auf Basis OCCU)
Wohnort: Dresden
Hat sich bedankt: 459 Mal
Danksagung erhalten: 1856 Mal
Kontaktdaten:

Re: CCU-Repository

Beitrag von jmaus » 10.12.2018, 14:34

quickmic hat geschrieben:
10.12.2018, 14:26
Waerst du bereit in dein bestehendes Repo die Aenderungen einzubauen? (https://github.com/jens-maus/occu)
Ja, dazu wäre ich bereit. In der Tat habe ich da auch schon teilweise selbst drangedacht aber dann aus Zeitmangel das nie verfolgt bzw. immer verschoben. Auch weil ich bisher immer die patches direkt an eQ3 gesendet habe und daran haben die sich eben gewöhnt :) Ich kann das ja aber auch aus dem OCCU fork heraus dann tun in der Hoffnung das die ihr buildsystem dann so anpassen das in Zukunft OCCU synchron ist mit der jeweiligen CCU firmware.
quickmic hat geschrieben:
10.12.2018, 14:26
Wie bereits erwaehnt, will ich eigentlich nicht Forken. Ausserdem ist endloses rumgeforke imho ohnehin nicht zielfuehrend. Das zersteut nur die Basis und irgendwann kennt sich keiner mehr aus.
Nun, ich sag mal so: Git ist dein Freund :) Du solltest dann ohnehin zumindest mein fork wieder Forken und mir dann z.B. via pull requests Änderungswünsche zukommen lassen. So entwickelt man im Jahr 2019 und nicht durch das hin/her reichen bzw. beschreiben von änderungen/patches ;-)

Und wie ich in dem anderen Fred bereits geschrieben hatte – für deine x86 OCCU Anpassungen wäre es ohnehin sinnvoll wenn du dafür mal ein GitHub Projekt starten könntest und dann dort alles sammelst und ein build environment drumherum machst damit man das in einfachster Art&Weise nicht nur nachvollziehen sondern auch dann umsetzen kann.
quickmic hat geschrieben:
10.12.2018, 14:26
Ich hab jetzt die Differenzen durchgeschaut. Ist granicht so schlimm wie ursprunglich angenommen. Zumindest in Bezug auf den www, Folder.
Die Differenzen sind in der Tat nicht so groß (1-2 Dateien) und es gibt z.B. auch Dateien die berechtigterweise im OCCU repo neuer/anders sind als in der CCU3 firmware. Wenn ich meinen Fork also mit den notwendigen Patches vom RaspberryMatic git auf den Stand gebracht habe kannst du dir das gerne noch einmal anschauen um mir dann sagen wo du noch Änderungsbedarf siehst.
RaspberryMatic 3.75.6.20240316 @ ProxmoxVE – ~200 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker + HomeAssistant – GitHub / Sponsors / PayPal / ☕️

quickmic
Beiträge: 518
Registriert: 20.01.2011, 14:39
Hat sich bedankt: 5 Mal
Danksagung erhalten: 4 Mal

Re: CCU-Repository

Beitrag von quickmic » 10.12.2018, 15:02

Auf CCU auch neuer:
\opt\HmIP\hmip-copro-update.jar
\opt\HmIP\legacy-parameter-definition.config
\firmware\RPI-RF-MOD\fwmap

Ja, ich weiss das GIT/SVN usw. seine Vorteile haben. Ich hab indirekt auch beruflich damit zu tun.
Ich programmiere zwar selbst nur als Hobby, aber ich analysiere beruflich sehr viele Codes die andere geschreiben haben in verschiedensten Programmierspraechen. -> Sourcecode-Reviews :wink:
Kommt halt immer drauf an. Wenn nur ein Einziger dran arbeitet ist das imho sinnloser Overhead. Wenn wirklich verteilt an einem Projekt gearbeitet wird, absolut sinnvoll.

Wegem dem X86 Code ist das noch eine andere Baustelle.
Vielleicht Fork ich echt nochmal dein Repo. Im Moment hat aber fuer mich Prioritaet 1 ein sauberes Repo zu erhalten. Das ist die Basis, und alles anderen entwickelt sich dann von dem herraus.

Benutzeravatar
jmaus
Beiträge: 9819
Registriert: 17.02.2015, 14:45
System: Alternative CCU (auf Basis OCCU)
Wohnort: Dresden
Hat sich bedankt: 459 Mal
Danksagung erhalten: 1856 Mal
Kontaktdaten:

Re: CCU-Repository

Beitrag von jmaus » 10.12.2018, 16:58

quickmic hat geschrieben:
10.12.2018, 15:02
Ja, ich weiss das GIT/SVN usw. seine Vorteile haben. Ich hab indirekt auch beruflich damit zu tun.
Ich programmiere zwar selbst nur als Hobby, aber ich analysiere beruflich sehr viele Codes die andere geschreiben haben in verschiedensten Programmierspraechen. -> Sourcecode-Reviews :wink:
Kommt halt immer drauf an. Wenn nur ein Einziger dran arbeitet ist das imho sinnloser Overhead. Wenn wirklich verteilt an einem Projekt gearbeitet wird, absolut sinnvoll.
Das stimmt auch nur sehr bedingt. Ich nutze auch selbst für Projekte in die ich nur selbst reinschaue SVN/GIT. Das bringt einfach mehr Vorteile als das es overhead macht und man kann schnell mal nach einer regression schauen und auf Vorversionen zurückgehen. Leider aber verwechseln viel zu viele Leute SVN und GIT mit einer Art Backup oder System das man nur dann einsetzt wenn man mit mehreren Personen an was arbeitet.
quickmic hat geschrieben:
10.12.2018, 15:02
Wegem dem X86 Code ist das noch eine andere Baustelle.
Ich wäre in der Tat sehr interessiert eine x86 Version von RaspberryMatic (wie auch Immer geartet) zu sehen. Eben nicht als flash image, dann aber als shell Skripts oder Debian install packages, etc. Im Grunde sollte sowas in buildroot problemlos möglich sein.
quickmic hat geschrieben:
10.12.2018, 15:02
Vielleicht Fork ich echt nochmal dein Repo. Im Moment hat aber fuer mich Prioritaet 1 ein sauberes Repo zu erhalten. Das ist die Basis, und alles anderen entwickelt sich dann von dem herraus.
Inzwischen habe ich nun mein OCCU fork wie besprochen erweitert und die CCU Firmware patches die ich bisher im RaspberryMatic repo gepflegt habe nun in meinen OCCU fork verschoben sodass alle OCCU Modifikationen nun an einer einzelnen Stelle sind. Schau mal nach, jetzt sollte das OCCU repo mit der CCU3 firmware besser im Einklang sein.
RaspberryMatic 3.75.6.20240316 @ ProxmoxVE – ~200 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker + HomeAssistant – GitHub / Sponsors / PayPal / ☕️

quickmic
Beiträge: 518
Registriert: 20.01.2011, 14:39
Hat sich bedankt: 5 Mal
Danksagung erhalten: 4 Mal

Re: CCU-Repository

Beitrag von quickmic » 10.12.2018, 18:18

Schaut schon sehr gut aus.
Ich werde mal versuchen mit deinem Repo jetzt mein Install-Script laufen zu lassen damit das einstweilen sauber funktioniert.
Paar Links sind noch in deinem Repo anders als auf der CCU3 aber nichts Schlimmes.
z.b. linkt in ccu3 das /www/cgi.tcl mittlerweile bereits direkt auf /www/tcl/extern/cgi.tcl und nicht mehr ueber den Umweg /opt/hm/www/tcl/extern/cgi.tcl
Ich patche das in meinem Script im Moment noch raus, ich vermute du auch beim Raspi.
Ich werde die anderen Links dann auch mal alle durchschauen, aber ist eher Kosmetik.

quickmic
Beiträge: 518
Registriert: 20.01.2011, 14:39
Hat sich bedankt: 5 Mal
Danksagung erhalten: 4 Mal

Re: CCU-Repository

Beitrag von quickmic » 14.12.2018, 12:42

Ich hab mir jetzt das Raspberrymatic git angeschaut was du da so machst, speziell das Makefile.
Bin mir nicht sicher ob es was bringt, das zu erweitern auf X86. Das ganze ist in erster Linie dafuer gedacht, ein komplettes Crosscompiling durchzufuehren und ein Image zu erstellen.

Ich werde jetzt ertsmal versuchen nur die Patches von dir (dynamisch aus dem git) zu uebernehmen und in meinem Script einzubauen. Wenn das klappt, koennte man natuerlich die Scripterstellung (oder deb) ins Makefile einbauen, aber ganz erschliesst sich mir der Vorteil hier nicht.
make verwenden um ein Script zu erstellen (oder deb). Da kann man gleich ein Script nehmen und nicht via make erst zusammenbauen zu lassen.

Benutzeravatar
jmaus
Beiträge: 9819
Registriert: 17.02.2015, 14:45
System: Alternative CCU (auf Basis OCCU)
Wohnort: Dresden
Hat sich bedankt: 459 Mal
Danksagung erhalten: 1856 Mal
Kontaktdaten:

Re: CCU-Repository

Beitrag von jmaus » 14.12.2018, 14:37

quickmic hat geschrieben:
14.12.2018, 12:42
Ich hab mir jetzt das Raspberrymatic git angeschaut was du da so machst, speziell das Makefile.
Bin mir nicht sicher ob es was bringt, das zu erweitern auf X86. Das ganze ist in erster Linie dafuer gedacht, ein komplettes Crosscompiling durchzufuehren und ein Image zu erstellen.

Ich werde jetzt ertsmal versuchen nur die Patches von dir (dynamisch aus dem git) zu uebernehmen und in meinem Script einzubauen. Wenn das klappt, koennte man natuerlich die Scripterstellung (oder deb) ins Makefile einbauen, aber ganz erschliesst sich mir der Vorteil hier nicht.
make verwenden um ein Script zu erstellen (oder deb). Da kann man gleich ein Script nehmen und nicht via make erst zusammenbauen zu lassen.
Nun, dann übersiehst du leider die Vorteile eine buildroot Umgebung bzw. hast leider noch keine Erfahrung im Bereich buildroot. Denn das ist mehr als nur eine build Umgebung um sich ein full-fledged sd karten image generieren zu lassen. Man kann dort Pakete definieren, Maschinen Beschreibungen hinterlegen, etc. sodass am Schluss nicht zwingend ein SD Karten image generiert werden muss oder auf dem Weg dahin auch kein Linux kernel generiert werden muss. Es können damit eben alle dependencies in geordneter Form eingesammelt und zusammengestellt werden. Schau dir einfach mal das "docker" defconfig file unter "buildroot-external/configs" an und schau da rein was da für Pakete definiert und nicht definiert werden.

Und letztendlich ist es egal ob du einen "install_script.sh" ausführst oder eben z.B. ein "make PRODUCT=raspmatic_x86_debian dist" ausführen lässt, das ding dann alles notwendige einsammeln, kompiliert, etc. um dann am Schluss z.B. ein Debian Paket zu generieren das man dann auf einem x86 Debian installieren lassen kann.

Mir ist hier natürlich klar das hier der Zeitaufwand für das einarbeiten in buildroot erheblich ist am Anfang (ging mir auch so). Allerdings werden einem die fundamentalen Vorteile dieses build systems sehr schnell klar wenn man erst einmal damit gearbeitet hat. Und ich bin gerne bereit – wenn du mir deine x86 skripte/anpassungen in geordneter Form aufbereitest – hier die Grundarbeiten bereits vorzunehmen und dir unter die Arme zu greifen damit du hier nicht alles von Grund auf selbst machen musst.
RaspberryMatic 3.75.6.20240316 @ ProxmoxVE – ~200 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker + HomeAssistant – GitHub / Sponsors / PayPal / ☕️

Benutzeravatar
deimos
Beiträge: 5383
Registriert: 20.06.2017, 10:38
System: Alternative CCU (auf Basis OCCU)
Wohnort: Leimersheim
Hat sich bedankt: 121 Mal
Danksagung erhalten: 950 Mal
Kontaktdaten:

Re: CCU-Repository

Beitrag von deimos » 14.12.2018, 14:49

Hi,

wie ich schon mal geschrieben habe: Die Macher von Buildroot sagen selber, dass man Buildroot nicht für das Erstellen von deb Paketen verwenden soll.
Siehe https://buildroot.org/downloads/manual/ ... y-packages

Und wenn man sich den ersten Satz der Doku anschaut, dann wird klar, dass es an sich nur gemacht ist, um komplette Linux Images zu erzeugen (nicht zwingend SD Karten, aber eben vollständige Images):
Buildroot is a tool that simplifies and automates the process of building a complete Linux system for an embedded system, using cross-compilation.
Rein anhand der Doku wüsste ich auch gar nicht, wie das gehen soll, da ist nur der Weg beschrieben deb Pakete zu nutzen.

Wenn man da was gemeinsam verwenden will, dann sollte man daher nicht Buildroot als Basis nehmen, sondern make, weil das ja von Buildroot als Basis genommen wird, aber Buildroot hat vieles mehr macht, was man an sich nicht braucht.

Viele Grüße
Alex

Antworten

Zurück zu „OCCU Entwicklung“