Beiträge von dlueth

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?

Hm, wieso geht es dann bei mir selbst? Als Dicker Container mit Zattoo Deutschland?

Du nimmst immer noch die Binaries direkt und nicht den Container, oder?

Starfoxfs soll ich in meinem Container mal ne etwas ältere Python Version probieren?

talentfrei Generell sicher eine gute Idee. In der Vergangenheit war es allerdings so, dass es immer mal wieder Probleme gab (und vermutlich gibt). Das lag aber weniger an dem Tool selber als vielmehr daran, dass viele ihre Container nur mit "latest" taggen. Erstens hatten die Tools damit ein Problem, weil sie halt nicht unterscheiden können (oder konnten) ob das gerade verwendete Latest dem Latest im Hub entspricht und zweitens, weil ggf. ein Rollback auf die vorige Version damit nahezu unmöglich ist (oder war).