Beiträge von dlueth

Starfoxfs ja, aber das ist noch das bullseye-build. Das angehängte wäre Buster, also die vorige debian-Version

So, wie versprochen dann einmal das arm64 binary sowie das für arm auf Basis von Buster - das ist die aktuelle Version 0.10.3. Wäre schön, wenn Ihr das nochmal testen könntet copain und Starfoxfs

Zitat von copain

dlueth armhf

Vielen Dank für Deine Bemühungen, die ich sehr schätze!

Deine Binary aus Post #111 läuft auf meinem System. Das Rückkopieren der settings.json hat allerdings nicht funktioniert. Ich musste mit der api eine neue generieren. Unterschied: NEUE uuid und refresh_token LEER ("").

GLIBC Abfrage:

ldd --version

ldd (Debian GLIBC 2.28-10+rpi1) 2.28

Es scheint, wenn Du Buster zum Generieren des Images verwendest, sollte es funktionieren.

Frage: Ist in Deinem Repo die armhf der Version 0.10.3 bereits auf Basis Buster? Falls dem so wäre, würde ich das Update mit dem Script ausführen.

Selbstverständlich stehe ich für weitere Tests gerne zur Verfügung.

Alles anzeigen

was die settings.json angeht: das war wie gesagt noch eine ältere Version die ich da für Dich gebaut habe, nicht die ganz aktuelle. Generell kann das aber schon sein, weil Easy ja ein paar Sachen angepasst hatte in Sachen "ID-Generierung", wobei ich zugebenermaßen nicht genau weiß, was er da gemacht hat.

copain & Starfoxfs denke morgen früh gibts 2 builds (arm64 ist schon durch, arm läuft noch) für euch zum testen mit der aktuellen telerising version. Laufen die schieb ich das ins repo und mach einen manuellen release. Ab dem nächsten Release von easy läuft's dann wieder vollautomatisch

copain ne, das war jetzt erstmal nur ein schnelles Test-Build für Dich, wohl auch noch nicht mit der aktuellen Version.

Starfoxfs ne, die bleiben bestehen, so oder so. Ich müsste nur sicherstellen, dass die arm64 builds auch auf Buster Basis (anstelle von bullseye) laufen.

Sollte hier noch jemand mit nem RPI mit 32 bit OS unterwegs sein könntet Ihr mir einen gefallen tun und mal folgendes Binary testen:

Download Data package from June 4th.

filetransfer.io

Feedback bitte ggf. per PM oder in meinem telerising.minimal Thread.

Wer mag kann mal die folgende arm (32 bit) binary ausprobieren die potentiell auf den RPIs dieser Welt laufen könnte die noch mit 32 bit laufen:

Download Data package from June 4th.

filetransfer.io

Starfoxfs Sollte die auf den 32 bit Systemen laufen baue ich nochmal eine explizite 64 bit Version davon für Dich zum Testen. Sollte alles laufen gehe ich zurück auf Buster als Baseimage anstelle von Bullseye

copain Hast Du in etwa die folgende Version?

Debian GLIBC 2.28-10+deb10u2

Wenn Python 3.9 für die binary vs 3.7 bei Dir auf dem System nicht das Problem ist hilft es vielleicht einfach den Build in Buster anstatt Bullseye zu machen, was sehr einfach wäre.

0.10.3 steht seit ca 2 Stunden zur Verfügung. Ich plane mich mit copain 's Problem zu beschäftigen, denn mein arm binary war ansich für die älteren rpi gedacht. Kann ich Dich ggf. zum Testen nutzen copain ?

Zitat von easy4me

Da ich erfahren habe, dass es u.a. bei 1und1 TV gewisse Gerätelisten gibt, die an die Device-UUIDs gebunden sind, habe ich soeben ein Update veröffentlicht, welches die Änderung zur dynamischen Erstellung der IDs rückgängig macht.

Und da ich meinen Raspberry nach Updates etc. nicht mehr korrekt hochfahren konnte, musste das System neu aufgesetzt werden. Somit läuft das Gerät jetzt mit 64bit - die armhf-Builds fallen somit meinerseits weg, dafür gibt es nun die arm64-Version jetzt im Repo.

Ein release dafür hattest Du noch nicht gemacht, oder? easy4me

Was armhf angeht: ich hab ja bei mir in den releases für telerising.minimal auch arm-builds die eigentlich laufen sollten. Mag das mal jemand testen?

Wenn die so nicht laufen sollten könnte ich wohl ein wenig rumprobieren.

Das hatte ich mich damals auch schon gefragt und habe es auch schon nicht wirklich beantwortet bekommen. Eigentlich kann das nur durch das falsche reingeben eines volumes vom Host passieren. Das müsste dann aber halt streng genommen auf / passieren, was aber nicht laufen dürfte dann.

So, nach erfolgreichem Testing durch Starfoxfs auf Basis von Python 3.9 gibt es jetzt im Docker Hub ein neues Latest auf dieser Basis sowie bei GitHub einen entsprechenden Release mit den Binaries dran.

Ab dem nächsten Release durch easy4me werden dann auch die automatischen Builds & Releases mit Python 3.9 erfolgen.

Ich muss mich korrigieren, da der docker Container ein scratch Image verwendet sollten die Binaries streng genommen überhaupt nichts zusätzlich brauchen

armhf sollte arm/v7 sein, zu 100% so weit ich das in Erfahrung bringen konnte. Sollte also laufen. Die Binaries benötigen zur Laufzeit eigentlich kein Python auf dem Zielsystem, glibc wohl aber schon.

copain dein System ist aber schon aktuell gehalten was die packages angeht, oder?

Nur mal so am Rande: Sollten nicht meine arm-Binaries (also nicht die arm64) eigentlich auf dem RPI laufen?

Ich hab gestern für Starfoxfs eine Version der arm64 binary auf Basis von Python 3.9.15 gebaut die er jetzt testet. Sollte das klappen testen wir noch 3.9.16, was die aktuelle 3.9er Version ist.

Nachwievor irritiert mich allerdings, dass mein Container immer schon Python 3.10 verwendet hat und die von easy4me angesprochenen Änderungen dort scheinbar auch immer schon so drin waren. Es hätte also eigentlich noch nie funktionieren dürfen, was aber nicht der Fall war.

Ich hab gerade mal geschaut: Basis meines Containers und damit auch der Binary builds war und ist schon immer das offizielle Python Image "python:3.10-slim-bullseye". Dort hat es in der Tat nach dem Build der Telerising Version 0.9.9 mindestens ein Update gegeben. Am selben Tag gab es auch eines für "python:3.9-slim-bullseye". Da mein Container schon immer mit 3.10 gebaut wurde kann das auch eigentlich kein grundsätzliches Problem von 3.10 sein, denn dann wäre es schon immer da gewesen.

Ich würde nur ungern manuell auf eine ältere Version des 3.10er images umstellen, weil es ja durchaus einen Grund für Updates gibt. Ich könnte es mal mit 3.9 versuchen, wobei mich die Tatsache der zeitgleichen Updates 3.9/3.10 im Docker Hub dafür stutzig macht.

Was meint Ihr?

Bei mir auch nicht, zumindest nicht dort - und er hat da auch eigentlich nichts zu suchen. Meine Vermutung damals war, dass das Volume falsch reingegeben wurde und evtl. das /proc aus dem Container so mit persistiert wird

Ne, das ist amd64 bei mir. Aber wenn es an Python liegt dürfte es doch mit der Architektur nichts zu tun haben imho?