[clausmuus]

Ja, das dürfte für den RPI sein.
Für den BPI und vor allem die WeTek müssen wir aber wohl selber kompilieren. Wobei sich die Frage stellt, wo man die nötigen Kompile Optionen her bekommt...

Claus

[TimUx]

Gut,
für den RPI passe ich mal mein Skript an, sodass das offiziellen Raspian Repo genutzt wird.

Gruß Timo

[sixpack]

@Claus,
also ich kenne mich leider nicht wirklich so gut mit der neueren Hardware aus mangels Besitz, aber es gibt doch soweit ich weis Openelec für die Wetek, welches doch auf debian basiert? Könnte man deren Sourcen nicht nehmen?

[clausmuus]

Bist Du sicher das Openelec auf Debian basiert? Ich meine die verwenden einen anderen Paketmanager.

Ich hatte auch schon versucht deren Sourcen, bzw. Compile Anweisungen für den Bau des WeTek kodi zu finden, allerdings erfolglos. Ich hatte aber auch nicht wirklich ausgiebig gesucht. Falls Du da erfolgreicher sein solltest, und mir nen Tipp geben könntest, wäre super.

Claus

[sixpack]

Hm sorry... ja da hast du recht, openelec "is build from scratch"

Aber vielleicht gibt es hier ja etwas was du brauchen könntest?
http://wiki.openelec.tv/index.php/Compile_from_source


[offtopic]
Was läuft eigentlich besser so ein RPI 2 oder solch eine Wetek, was ist Stromsparender? (Überlege gerade umzustellen)

[clausmuus]

Bisher noch der RPI 2. Für die WeTek gibt es noch kein voll funktionsfähiges VDR Frontend. Stromverbrauch dürfte ähnlich sein.

Claus

[TimUx]

Hallo Zusammen,
vielleicht könnte auch OSMC was sein.

https://osmc.tv/

Dies basiert definitive auf Debian und soweit ich gelesen habe, ist das ganze normale APT dabei und man kann jede beliebige Software nutzen.

Hatte auch schon mal überlegt, ein OSMC als Source System für einen MLD DEVEL zu nutzen.
Im Moment fehlt mir aber leider die Zeit.

Gruß Timo

[sixpack]

@Claus das hatte ich auch gemeint, ich sollte mir wirklich mal neue Minihardware anschaffen THX Timux

[TimUx]

Hallo zusammen,
hier die neueste Version des install Skriptes.

Ich habe nur Kleinigkeiten geändert.

Wenn ich wieder etwas Zeit finde, werde ich die initial zu installierenden Pakete mal etwas ausdünnen.
Eventuell müssen wir dann noch das eine oder andere Make-File anpassen, sodass wirklich alles notwendige mit einem "make deps" installiert wird.

Gruß Timo

PS:
Es darf das skript getestet werden.
Sobald ich es dann ausgedünnt habe, könnte man es aus dem Beta Status heraus nehmen. 

[tux76]

Hallo TimUx,

vielen Dank für das sehr nützliche Script!
Teste es gerade am Raspi2 und werde gerne Feedback geben.

Kann/soll dafür eigentlich Raspbian Jessie oder Wheezy verwendet werden?
Hab nämlich bemerkt, dass es unter Jessie einige Pakete nicht mehr/noch nicht gibt, die für den Build einiger vdr-plugins benötigt werden.

LG,
Martin

[BobW]

Hi Timo,

habe Dein Skript auf einem RPi2 mit raspian-jessie-light (laut Deiner Empfehlung) laufen lassen und dabei Folgendes festgestellt:

1. sudo ohne password ist bereits installiert (für den default user pi)
2. Der Pfad ist ebenfalls bereits angepasst, d.h. alle "root-Kommandos" sind nach Installation bereits verfügbar.

Ich schlage daher vor, den Ablauf umzustellen und

1. sudo ohne password nach Architekturabfrage an den Anfang zu stellen und nur für x86 durchzuführen
2. Pfadanpassung nur für x86 durchzuführen

Damit wären die Befehle auf beiden Systemen in der Folge gleich.

Das Gesagte gilt für Version 0.4.

Die Kompilierung dauert auf meinem RPi2 (900 Mhz, default) rund 13 Stunden.

Vielleicht wäre es auch nicht schlecht, für die MLD notwendige Pakete, die zum Betrieb des Entwicklungssystems aber nicht gebraucht werden, zu deaktivieren bzw. zu stoppen. Vor allem auf dem RPi mit seinem begrenzten RAM verschafft das dem Compiler doch ein wenig mehr freien Speicher.
Ich deaktiviere derzeit:

Code: [Select]

sudo service mysql stop
sudo service smbd stop
sudo service pilight stop
sudo service avahi-daemon stop

Möglicherweise wäre es auch sinvoll, für aus dem Skript resultierende notwendige Änderungen an der MLD-Entwicklungsumgebung jeweils einen eigenen Thread in "Entwicklung" aufzumachen und im Betreff mit dem Skript zu verlinken. Ich muss gestehen, ich verliere schön langsam den Überblick, was zum Skript gehört und was schlussendlich zur MLD.

Schöne Grüße aus Wien
BobW

[TimUx]

Hi,
das Skript ist auf Jessie ausgelegt, so wie alles bei MLD. 

Die Anpassungen des Sudo und Pfad architektur abhängig zu machen, wäre machbar.
Die Frage ist nur, ob es dann auch auf einem BPI noch läuft.
[EDIT]
Und was wäre, wenn ein anderer User als "pi" genutzt werden soll, dann müssen die Anpassungen auch durchgefürt werden.
Es wäre also eher eine Architektur unabhängige Prüfung des Sudo und Pfades für den aktuellen User interessant.
Wenn Sudo oder der Pfad nicht stimm, wird er angepasst.

Das stoppen der Dienste macht Sinn, werde ich mal mit einbauen.
Habe für x86 eh noch einen kleinen Bug drin.

Die v0.6 kommt bald. 

Gruß Timo

[MegaX]

Hi Timo,

wenn du für spotify ne neuere Version haben willst, dann stell mal in der sources.list von stable auf testing um.

[clausmuus]

Hi,

ich habe auch noch einen Wunsch für eine spätere Version des Scriptes. Ich würde mir wünschen, das es damit auch möglich ist, nicht nur eine komplette Entwicklungsumgebung zu erstellen, sondern auch eine solche, die nur die Teile enthält, um ein base Imgae zu erstellen. Also nur das was beim aufruf eines "make" im MLD Ordner erstellt wird.

Claus

[TimUx]

Hi Claus,
das sollte bestimmt kein Problem sein, mit entsprechender Abfrage am Anfang des Skriptes.

Für das "base image" müssen aber bestimmt auch deps installiert werden, oder?
Im Moment wird ja mit einem "make checkout_all" und einem "apt-get install $(make deps) alles installiert.
Was genau müssten man ändern, dass nur das base gezogen und dessen deps installiert werden?
Vielleicht was in der art "make checkout name=base"?

Gruß Timo