Build auf Raspberry Pi
18 views
Skip to first unread message
Christian Leutloff
Mar 30, 2016, 1:32:57 PM3/30/16
to Berg CMS Discussion
Hallo Björn,
ich finde die Idee gut, dass du das Redaktionsystem Berg CMS auch auf
dem Raspberry Pi betreiben willst. Dafür fehlen derzeit noch die Binärpakete.
Ich habe deswegen ein neues Repository auf GitHub angelegt, in dem wir den
Build von ARM-Paketen für deinen Pi angehen können:
https://github.com/leutloff/bergcms-build-arm
Der Build im Internet hat zwei Vorteile. Zum haben wir beide
Zugriff auf den gleichen Stand und zum anderen kann die
Arbeit dauerhaft genutzt werden, um neue Versionen zu bauen
und zu testen.
Ich habe als möglichen Weg bisher nur chroot mit QEMU gefunden. Siehe
README.md in dem neuen Repository. Kennst du einen besseren Weg?
Da sind auch die Infos bzgl. Travis CI erkennbar.
Wenn du einen Pull-Request erzeugst, wird automatisch der Build in
Travis CI ausgelöst und das Ergebnis beim Pull-Request mit angezeigt.
Sollte schon jetzt funktionieren, wenn die Datei .travis.yml ergänzt
wird.
Wenn du die Chroot so vorbereitest, dass sie deinem Zielsystem
entspricht, steuere ich gerne den eigentlichen Build vom Berg CMS bei.
In dem Dockerfile von https://github.com/leutloff/bergcms-build-debian
sind die notwendigen Schritte erkennbar, um zu einer Build-Umgebung zu
kommen. Zu der Build-Umgebung gehören neben gcc/g++ oder clang auch die
Schritte zur Installation von CMake 3.5 und Boost 1.58.0.
Den Build von ctemplate würde ich weglassen. Dafür muss dann beim
Aufruf von cmake das relativ neue Flag USE_CTEMPLATE auf FALSE gesetzt
werden:
cmake -D CMAKE_BUILD_TYPE=Distribution -D CMAKE_VERBOSE_MAKEFILE=FALSE -D Boost_DEBUG=FALSE -D USE_CTEMPLATE=FALSE "$BGDIR/src"
Ich hoffe, dass wir so rasch zu einem voll funktionsfähigen Redaktionssystem
auf deinem Pi kommen.
Viele Grüße
Christian
ich finde die Idee gut, dass du das Redaktionsystem Berg CMS auch auf
dem Raspberry Pi betreiben willst. Dafür fehlen derzeit noch die Binärpakete.
Ich habe deswegen ein neues Repository auf GitHub angelegt, in dem wir den
Build von ARM-Paketen für deinen Pi angehen können:
https://github.com/leutloff/bergcms-build-arm
Der Build im Internet hat zwei Vorteile. Zum haben wir beide
Zugriff auf den gleichen Stand und zum anderen kann die
Arbeit dauerhaft genutzt werden, um neue Versionen zu bauen
und zu testen.
Ich habe als möglichen Weg bisher nur chroot mit QEMU gefunden. Siehe
README.md in dem neuen Repository. Kennst du einen besseren Weg?
Da sind auch die Infos bzgl. Travis CI erkennbar.
Wenn du einen Pull-Request erzeugst, wird automatisch der Build in
Travis CI ausgelöst und das Ergebnis beim Pull-Request mit angezeigt.
Sollte schon jetzt funktionieren, wenn die Datei .travis.yml ergänzt
wird.
Wenn du die Chroot so vorbereitest, dass sie deinem Zielsystem
entspricht, steuere ich gerne den eigentlichen Build vom Berg CMS bei.
In dem Dockerfile von https://github.com/leutloff/bergcms-build-debian
sind die notwendigen Schritte erkennbar, um zu einer Build-Umgebung zu
kommen. Zu der Build-Umgebung gehören neben gcc/g++ oder clang auch die
Schritte zur Installation von CMake 3.5 und Boost 1.58.0.
Den Build von ctemplate würde ich weglassen. Dafür muss dann beim
Aufruf von cmake das relativ neue Flag USE_CTEMPLATE auf FALSE gesetzt
werden:
cmake -D CMAKE_BUILD_TYPE=Distribution -D CMAKE_VERBOSE_MAKEFILE=FALSE -D Boost_DEBUG=FALSE -D USE_CTEMPLATE=FALSE "$BGDIR/src"
Ich hoffe, dass wir so rasch zu einem voll funktionsfähigen Redaktionssystem
auf deinem Pi kommen.
Viele Grüße
Christian
Christian Leutloff
Apr 1, 2016, 2:13:00 PM4/1/16
to Berg CMS Discussion
Hi,
ich habe nun schon ein Travis-File angelegt und dafür gesorgt, dass ein Ubuntu 14.04 (statt des voreingestellten 12.04) verwendet wird. Auch die Pakete auf x64-Seite habe ich schon installiert. Jetzt fehlt noch der ARM Teil...
Viele Grüße
Christian
ich habe nun schon ein Travis-File angelegt und dafür gesorgt, dass ein Ubuntu 14.04 (statt des voreingestellten 12.04) verwendet wird. Auch die Pakete auf x64-Seite habe ich schon installiert. Jetzt fehlt noch der ARM Teil...
Viele Grüße
Christian
bjoernbialy
Apr 5, 2016, 3:07:50 PM4/5/16
to Berg CMS Discussion
Hi,
ich habe heute Abend den letzten Build auf meinen Programmier-PI geladen ( mit Standard raspian Nutzernamen). Ich wollte damit ich es lokal testen mit dem Build das ganze per deploy_ssh auf den Pi in der Gemeinde hochladen.
Der Aufruf deploy_ssh.sh -t prod -c all führt zu einem ssh Aufbau auf den Rechner prod mit login pi.
Im Skript habe ich die Zielpfade und auch DEPLOYTO angepasst passend für den Login in der Gemeinde.
Kein login möglich, da der Rechner prod nicht existiert ist ja logisch.
Der Aufruf deploy_ssh.sh -t bjoer...@aachen-feg.dnshome.de -c all führt, zu "Invalid deploment type: bjoern..."
und :
deploy_ssh.sh -t prod bjoer...@aachen-feg.dnshome.de -c all führt, zu "Missing components"
kannst du mal mit bitte ein remotehosts.cfg example zukommen lassen ich würde das gerne ausprobieren.
Reiner ssh bjoer...@aachen-feg.dnshome.de funktioniert ohne Probleme.
Viele Grüße Björn
ich habe heute Abend den letzten Build auf meinen Programmier-PI geladen ( mit Standard raspian Nutzernamen). Ich wollte damit ich es lokal testen mit dem Build das ganze per deploy_ssh auf den Pi in der Gemeinde hochladen.
Der Aufruf deploy_ssh.sh -t prod -c all führt zu einem ssh Aufbau auf den Rechner prod mit login pi.
Im Skript habe ich die Zielpfade und auch DEPLOYTO angepasst passend für den Login in der Gemeinde.
Kein login möglich, da der Rechner prod nicht existiert ist ja logisch.
Der Aufruf deploy_ssh.sh -t bjoer...@aachen-feg.dnshome.de -c all führt, zu "Invalid deploment type: bjoern..."
und :
deploy_ssh.sh -t prod bjoer...@aachen-feg.dnshome.de -c all führt, zu "Missing components"
kannst du mal mit bitte ein remotehosts.cfg example zukommen lassen ich würde das gerne ausprobieren.
Reiner ssh bjoer...@aachen-feg.dnshome.de funktioniert ohne Probleme.
Viele Grüße Björn
--
You received this message because you are subscribed to the Google Groups "Berg CMS Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bergcms-discu...@googlegroups.com.
To post to this group, send email to bergcms...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bergcms-discuss/51fa7bbd-2430-46b2-993b-857aa31febfe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
-- ############################################################ # Björn Bialy # # Vetschauer Weg 11 # 52072 Aachen # Tel.: 0241/4005446 # # Mobil: 0176/83021276 # E-Mail: bjoer...@bbialy.de ############################################################
Christian Leutloff
Apr 5, 2016, 6:36:03 PM4/5/16
to Berg CMS Discussion, bjoer...@bbialy.de
Wenn du DEPLOYTO angepasst hast, rufst du das Script einfach ohne den optionalen Parameter -t auf:
./deploy_ssh.sh -c all
On Tuesday, April 5, 2016 at 9:07:50 PM UTC+2, bjoernbialy wrote:
Hi,
ich habe heute Abend den letzten Build auf meinen Programmier-PI geladen ( mit Standard raspian Nutzernamen). Ich wollte damit ich es lokal testen mit dem Build das ganze per deploy_ssh auf den Pi in der Gemeinde hochladen.
Der Aufruf deploy_ssh.sh -t prod -c all führt zu einem ssh Aufbau auf den Rechner prod mit login pi.
Im Skript habe ich die Zielpfade und auch DEPLOYTO angepasst passend für den Login in der Gemeinde.
Kein login möglich, da der Rechner prod nicht existiert ist ja logisch.
Der Aufruf deploy_ssh.sh -t bjoernbialy@aachen-feg.dnshome.de -c all führt, zu "Invalid deploment type: bjoern..."
und :
deploy_ssh.sh -t prod bjoernbialy@aachen-feg.dnshome.de -c all führt, zu "Missing components"
kannst du mal mit bitte ein remotehosts.cfg example zukommen lassen ich würde das gerne ausprobieren.
Reiner ssh bjoernbialy@aachen-feg.dnshome.de funktioniert ohne Probleme.
Viele Grüße Björn
Am 01.04.2016 um 20:13 schrieb Christian Leutloff:
Hi,
ich habe nun schon ein Travis-File angelegt und dafür gesorgt, dass ein Ubuntu 14.04 (statt des voreingestellten 12.04) verwendet wird. Auch die Pakete auf x64-Seite habe ich schon installiert. Jetzt fehlt noch der ARM Teil...
Viele Grüße
Christian
-- ############################################################ # Björn Bialy # # Vetschauer Weg 11 # 52072 Aachen # Tel.: 0241/4005446 # # Mobil: 0176/83021276 # E-Mail: bjoer...@bbialy.de ############################################################
Christian Leutloff
Apr 5, 2016, 6:45:30 PM4/5/16
to Berg CMS Discussion, bjoer...@bbialy.de
Ich habe nun auch ein Beispiel eingecheckt und de Option -t korrigiert. Aber Skript ist nicht getestet...
On Tuesday, April 5, 2016 at 9:07:50 PM UTC+2, bjoernbialy wrote:
Hi,
ich habe heute Abend den letzten Build auf meinen Programmier-PI geladen ( mit Standard raspian Nutzernamen). Ich wollte damit ich es lokal testen mit dem Build das ganze per deploy_ssh auf den Pi in der Gemeinde hochladen.
Der Aufruf deploy_ssh.sh -t prod -c all führt zu einem ssh Aufbau auf den Rechner prod mit login pi.
Im Skript habe ich die Zielpfade und auch DEPLOYTO angepasst passend für den Login in der Gemeinde.
Kein login möglich, da der Rechner prod nicht existiert ist ja logisch.
Der Aufruf deploy_ssh.sh -t bjoernbialy@aachen-feg.dnshome.de -c all führt, zu "Invalid deploment type: bjoern..."
und :
deploy_ssh.sh -t prod bjoernbialy@aachen-feg.dnshome.de -c all führt, zu "Missing components"
kannst du mal mit bitte ein remotehosts.cfg example zukommen lassen ich würde das gerne ausprobieren.
Reiner ssh bjoernbialy@aachen-feg.dnshome.de funktioniert ohne Probleme.
Viele Grüße Björn
Am 01.04.2016 um 20:13 schrieb Christian Leutloff:
Hi,--
ich habe nun schon ein Travis-File angelegt und dafür gesorgt, dass ein Ubuntu 14.04 (statt des voreingestellten 12.04) verwendet wird. Auch die Pakete auf x64-Seite habe ich schon installiert. Jetzt fehlt noch der ARM Teil...
Viele Grüße
Christian
You received this message because you are subscribed to the Google Groups "Berg CMS Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bergcms-discuss+unsubscribe@googlegroups.com.
To post to this group, send email to bergcms-discuss@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bergcms-discuss/51fa7bbd-2430-46b2-993b-857aa31febfe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
bjoer...@googlemail.com
May 5, 2016, 2:33:00 PM5/5/16
to Berg CMS Discussion
Hi Christian,
das skript funktioniert, ich habe es endlich geschafft es zu testen.
Dabei sind mir ein paar dinge aufgefallen wo ich weiß das du dir dabei was gedacht hast, aber es meinem Verständnis/wissen über multiplattform Programmierung widerspricht und Anwendungsentwicklung für DAUS nicht entspricht.
1.) Warum nutzt du für die boost-libs die Version bezogenen lib's und nicht die lib's die Versionsbefreit sind?
2.) Ist nicht ein großteil der boost libs in c++11 mit eingezogen? Benutzt du funktionen die nicht in c++11 enthalten sind, aber noch in der boost lib? Desto mehr wir auf Standart Libs runterbrechen können desto weniger Zusatz lib's werden benötigt und die Plattformunabhängig steigt.
3.) Durch die Boost reduzierung in dem Programm werden die cmake-dateien einfacher und können dann leichter auf verschiedene Hardware architekturen umgesetzt werden. QENUM wird zwar dann weiterhin gebraucht, aber es wird für dritte leichter das ganze umzusetzen.
4.) Strukturelle Frage: warum befindet sich das "statische" Layout noch im CGI-Script. Ich würde vermuten, das die Installation und das Handling sich verbessern wenn man die Datenbank (.csv, .xml oder db), Latex2PDF und Frontend von einander trennt. So kann man die drei Bereiche unabhänig von einander pflegen und die Fehlersuche und Beseitigung wird erleichtert.
Grüße Björn
das skript funktioniert, ich habe es endlich geschafft es zu testen.
Dabei sind mir ein paar dinge aufgefallen wo ich weiß das du dir dabei was gedacht hast, aber es meinem Verständnis/wissen über multiplattform Programmierung widerspricht und Anwendungsentwicklung für DAUS nicht entspricht.
1.) Warum nutzt du für die boost-libs die Version bezogenen lib's und nicht die lib's die Versionsbefreit sind?
2.) Ist nicht ein großteil der boost libs in c++11 mit eingezogen? Benutzt du funktionen die nicht in c++11 enthalten sind, aber noch in der boost lib? Desto mehr wir auf Standart Libs runterbrechen können desto weniger Zusatz lib's werden benötigt und die Plattformunabhängig steigt.
3.) Durch die Boost reduzierung in dem Programm werden die cmake-dateien einfacher und können dann leichter auf verschiedene Hardware architekturen umgesetzt werden. QENUM wird zwar dann weiterhin gebraucht, aber es wird für dritte leichter das ganze umzusetzen.
4.) Strukturelle Frage: warum befindet sich das "statische" Layout noch im CGI-Script. Ich würde vermuten, das die Installation und das Handling sich verbessern wenn man die Datenbank (.csv, .xml oder db), Latex2PDF und Frontend von einander trennt. So kann man die drei Bereiche unabhänig von einander pflegen und die Fehlersuche und Beseitigung wird erleichtert.
Grüße Björn
Christian Leutloff
Sep 19, 2016, 12:51:22 PM9/19/16
to Berg CMS Discussion
Hallo Björn,
mir ist die Nachricht durchgeflutscht. Sorry.
Zum Hintergrund: Das Berg CMS ist schon viele viele Jahre alt. Die von dir angesprochenen Änderungen muss halt jemand machen...
zu 1)
Weil das Berg CMS auch funktionieren soll, wenn im System andere Boost-Versionen installiert sind. Die Annahme ist, dass man auf das hostende System keinen Einfluss hat und deswegen autark sein will.
zu 2)
Muss jemand nur machen... Ich nehme gerne entsprechende Patches an.
zu 3)
siehe 2)
zu 4)
die Architektur war so... und sie funktioniert. Ich habe so viele funktionale Ideen, dass ich da sehr pragmatisch bin. Wie du am Quellcode siehst, baue ich gerade ein REST API auf, mit dem sich Frontend und Backend dann trennen lassen. Dabei gehe ich davon aus, dass ich ein CGI-Programm installieren kann, aber leider keinen eigenen Port habe.
Viele Grüße
Christian
mir ist die Nachricht durchgeflutscht. Sorry.
Zum Hintergrund: Das Berg CMS ist schon viele viele Jahre alt. Die von dir angesprochenen Änderungen muss halt jemand machen...
zu 1)
Weil das Berg CMS auch funktionieren soll, wenn im System andere Boost-Versionen installiert sind. Die Annahme ist, dass man auf das hostende System keinen Einfluss hat und deswegen autark sein will.
zu 2)
Muss jemand nur machen... Ich nehme gerne entsprechende Patches an.
zu 3)
siehe 2)
zu 4)
die Architektur war so... und sie funktioniert. Ich habe so viele funktionale Ideen, dass ich da sehr pragmatisch bin. Wie du am Quellcode siehst, baue ich gerade ein REST API auf, mit dem sich Frontend und Backend dann trennen lassen. Dabei gehe ich davon aus, dass ich ein CGI-Programm installieren kann, aber leider keinen eigenen Port habe.
Viele Grüße
Christian
Reply all
Reply to author
Forward
0 new messages