Neutrino-Images

Wie es auf der schnelle aussah, gab es da eine git merge Opfer
Eine Änderung ist im Git, Bitte mal testen.

durch das neue pyinstaller.py wird python extern doch gebraucht, es sei man passt den Pfad an das BS an.

das Python kann da raus, ist je keine Abhängigkeit fürs BS und wird ja selber vom BS erzeugt. apt-get install \ git subversion mercurial cvs automake build-essential ccache tar \ texinfo autopoint libtool libtool-bin python curl lzma \ gettext help2man libglib2.0-dev libncurses5-dev libncursesw5-dev...

Ja das war uns auch zu viel zum bauen und haben uns für den kurzen weg entschieden, um es zu testen

plutoTV epg bekommt man auch mit https://github.com/4v3ngR/pluto_tv_scaper.git und node im image, daher meine Frage an der Stelle.

Mal eine Frage, geht es bei der ganzen Python und PlutoTV Sache nur um das EPG?

@vanhofen
ja hast recht, war wohl heute schon zu lange zwischen den Zeilen unterwegs

@vanhofen was mich jetzt wundert das es mit deiner Änderung jetzt auch durch baut. hatte arm-linux-gnueabihf genommen, weil alle so Dateien in usr/lib/python3.11/lib-dynload auch diesen Anhang haben und die Datei in der Abfrage wird auch diesen Namen benutzt _sysconfigdata__linux_arm-linux-gnueabihf...

bei python-lxml WARN: Option 'xml2-config' is deprecated. Use 'with-xml2-config' instead. WARN: Option 'xslt-config' is deprecated. Use 'with-xslt-config' instead. auch mal das anpassen, ist zwar nur warn aber man weiß ja nie PYTHON_LXML_BUILD_OPTS = \ --with-xslt-config=$(HOST_DIR)/bin/xslt-config ...

Nichts zu Danken. Es hat mich bei mir nur gewundert, das die so Dateien inhaltlich richtig waren bei mir, nur der Name halt falsch. Habe dann deine ganze Python Arbeit, dann bei mir mal eingebaut (komme zum Testen mit dem fertigen Host im NI BS nicht klar ;-) ) und habe dann die selben Fehler wie im...

Nach etwas herumbasteln, kann ich nur sagen, es geht nun, auch mit dem construct, was vonhofen aus Buildroot zum teil übernommen hat. Damit die richtigen Namen erscheinen bei den so Dateien angewendet werden und alles richtig erkannt wird, ist folgendes wichtig bei Python3. PKG_PYTHON_HOST_PLATFORM ...

in der z.B builder.cpython-311-x86_64-linux-gnu.so steht auch alles mit arm und crosstool NG drin, wenn man sie mal mit GHex betrachtet, als ob die Dateien nur einen falschen Namen bekommen.

Das NI-buildsystem, baut bei mir auch nicht, bekomme dann auch diesen LONG_BIT Fehler.
An der GCC Version kann es nicht liegen, habe dann selber mal mit 13 gebaut, und ging bei mir auch durch, bis auf das x86_64 in den so Dateien.

@jokel
das meinte ich den Tag, mit der Aussage zu CC

max_10 hat geschrieben: ↑Sa 13. Jan 2024, 20:30 @vanhofen
jetzt im log sehe ich auch was du mit CC meinst.

Der unterschied sollte nur der zusätzliche Patch bei mir sein
0032-use-legacy-path-for-pycs.patch
aus openembedded-alliance-core git, damit es diese Cashe Ordner nicht gibt und die pyc normal im Ordner sind.

@jokel du verstehst gerade nicht was ich meinte, es gibt bei mir nur *.py und *.pyc und nicht noch diese ganzen cacheordner unter usr/lib/python3.11 und das war gemeint wie unter E2, würde unter NI genau so gehen wenn es auch so gebaut ist und etwas fertiges mit opgk zu installieren ist ja keine Kun...

@vanhofen
jetzt im log sehe ich auch was du mit CC meinst.

@jokel
das wird dir nicht helfen, NI baut python fürs image mit diesem cache Ordner, ich lasse pyc bauen wie im E2 Image.

bitte schön

An der XML Version liegt es nicht, hier baut es durch, es ist schon so wie vanhofen sagt liegt an Python. kenne den Fehler auch noch von E2 unter sh4, weiß nur noch ungefähr das in pyport.h eine Zeile mit LONG_BIT entfernt werden. max@max:~/0_buildsystem-max-test$ make python-lxml >>> hd51 python-lx...