Beiträge von dlueth

PvD Es scheint als wenn GitHub etwas ausgelastet ist was die nötigen "Runner" für GitHub Actions angeht, der Build hängt noch - hab ihn gerade nochmal neu angefragt. Ich hab ein Auge drauf und geb bescheid...

PvD Build läuft, probierst die neue Version mal bitte?

DeBaschdi chmod ist auch noch nötig? komisch, dass das nicht vorher schonmal aufgefallen ist, oder? PvD ich kümmere mich darum

PvD Die Meldung kommt direkt aus EasyEPG, nicht vom Docker ansich, siehe hier. Mit welchem User startest Du denn den Docker? Es scheint diesbezüglich irgendetwas nicht zu stimmen. Sprich, der User den den Container startet bzw. der, der den Cronjob ausführt passt scheinbar nicht

Schau ich mir morgen an PvD - welches Tag nimmst Du beim Container?

Kenkodi was für ein System hast Du denn und mit welchem OS?

Welchen Tag von Docker benutzt Du denn? Scheinbar einen expliziten, denn eigentlich sollte "latest" automatisch die Architektur auswählen

0.10.4 ist fertig gebaut

0.10.4 build läuft, ETA ca 3-4h im Docker Hub und den GitHub releases. Ist dann das erste automatische Release auf Buster-Basis.

Jo, entweder so, oder Du nimmst meine Binaries XD

Easy sieht das erstellen der Binaries eh nicht als seine Hauptaufgabe an und macht das mehr weil er's muss. Und ob Docker oder nicht steht ja nachwievor jedem frei. Ich bevorzuge Docker, weil ich isolierte Umgebungen mit inkludierten Dependencies habe. Haue ich den Conainer weg ist mein System nachwievor sauber. Und ich kann ggf. auch das System neu installieren und schneller wiederherstellen.

DeBaschdi kein Problem, ich helfe wo ich kann

Was interessant ist:

Easy hat vorher seine armhf Binary auf einem 32-bit Buster gebaut. Die lief dann auch auf RPIs mit einem Raspian gleicher Basis. Das ist nun nicht mehr so. Du hast ja nun Deinen Container auf Bullseye hochgezogen, so das alles wieder zusammen passt. Sollte easy auf einem 64-bit System bauen, denn je nach RPI ist der ja durchaus 64-bit, dann wäre das jetzt eigentlich kein armhf build, sondern arm64 und dürfte auf armhf auch nicht mehr laufen.

Ich bin in die andere Richtung gegangen und habe meine binary builds auf Buster geändert. Daher laufen meine Binaries jetzt, anders als vorher, auch auf den softwaretechnisch älteren RPIs.

copain zukünftige automatische releases werden ab sofort immer auf Basis von Buster gebaut, für den Moment nicht mehr mit bullseye. Ich brauche dafür gar nichts zu tun das ist das schöne, wenn man den Kram via GitHub in Docker baut

Easy selbst hat das Problem jetzt wohl auch, denn sein rpi hat jetzt scheinbar auch bullseye drauf. Ergo haben es auch die Container von debaschdi

Ja: Es scheinen viele Leute ihre RPIs nicht upzudaten und/oder von 32-bit auf 64-bit umzustellen. Daher ergibt sich das Problem, dass die von mir bereitgestellten Binaries zwar generell auf arm aka armhf laufen, aber nicht, wenn das OS noch Buster-basiert ist. Die GLIBC-Version von Buster ist "zu alt" für die builds und da leider statische Builds unter Linux eben doch nicht ganz statisch sind wird das zum Problem.

Da wir ja aber nun wissen, dass eine unter Buster gebaute Binary durchaus auch auf Bullseye läuft kann ich da ja eine Version wieder runter gehen...

Jo, das dürfte dann Bullseye sein und damit die Ursache des problems für alle die noch Buster drauf haben

Build bei GitHub läuft für die 0.10.3 auf Debian Buster Basis, der Build wird wohl ca. 3-4 Stunden dauern und steht dann im Docker Hub als Image und auch bei den GitHub Releases als Binary bereit. Zukünftge Builds bei Release durch easy werden dann automatisch auch mit Buster gebaut und nicht mehr Bullseye

Starfoxfs kk danke - dann mach ich mich jetzt an den neuen release für die buster-version

Starfoxfs nimm bitte explizit die Version die ich oben verlinkt habe. Im Repo ist doch immer noch die Bullseye-Version und um die geht es ja nicht XD

DeBaschdi nimmt direkt das von easy4me bereitgestellte Binary für die jeweilige Architektur aus dessen öffentlichem Repo. Für arm64 wird dabei ebenfalls die arm32/armhf binary genommen. Ergo müsste in diesem Fall das Problem irgendwo bei easy liegen. Vermutung, da ich das auch gerade bei meinem minimal Docker durch hab:

Easy baut jetzt auf einem Bullseye basierenden Debian/Raspbian, und das läuft dann nicht auf einem Buster basierenden Debian/Raspbian weil Bullseye eine neuere GLIBC Version mitbringt

Zitat von copain

dlueth armhf

Dir nochmals Respekt und vielen Dank für den unermüdlichen und schnellen Einsatz, was keineswegs selbstverständlich ist!

armhf 0.10.3 Buster läuft auf meinem System. Wie in Post #113 beschrieben, erhielt ich nach dem manuellen Rückkopieren der settings.json erneut 'Errno 13 Permission denied /etc/telerising/settings.json'. Danach habe ich mit der api wieder eine neue generiert, mit neuer uuid und leerem refresh_token.

Ich hoffe, dass das Rückkopieren künftig nach Updates mit dem Script wieder normal funktioniert. Oder habe ich allenfalls etwas übersehen und einen Fehler gemacht?

Kein Problem. Wenn es jetzt total exotische/spezielle Anforderungen wären würd ich's vermutlich ablehnen aus Zeitmangel. Aber da es um die normalen arm-binaries geht die meinerseits genau für die 32-bit RPIs gedacht waren, was ich aber nicht selbst testen kann, machts irgendwie Sinn XD

copain sieht so aus als würdest Du das sichern/wiederherstellen der settings.json mit einem anderen Benutzer und/oder anderen Rechten machen als dem, der die Binary dann letztlich ausführt. Wie startest Du denn aktuell die Binary bzw. mit welchem User? Welche "Rechte" haben die neu angelegte und die gesicherte settings.json?