Beiträge von dlueth

Du hast da als target network-online drin. Ich vermute jetzt einfach Mal, dass das nicht zwingend bedeutet, dass eine Internetverbindung besteht. Es bedeutet vermutlich nur, dass eine Verbindung zu deinem lokalen Netzwerk besteht. Ich meine es gäbe aber darüber hinaus noch die Möglichkeit ergänzend einen zeitlichen delay für einen Service festlegen.

update.freak Ja, sollte, blos ohne den Forums Code beim Zweiten XD Es müsste aber auch ohne die tmpfs-Sachen gehen zur Not - aber besser mit

Hilft das evtl? https://stackoverflow.com/questions/4190…pfs-not-working

Jo, das ist dann Scheisse leider. Bedeutet im Kern vermutlich, dass das alignment ohne diesen fix nicht dem normalen Debian für Arm 64 entspricht

Icke1260 Wobei das halt nur für telerising selbst gilt. Das OS im Container bleibt auf dem Stand von vor 7 Monaten. Das kann man gut finden oder auch nicht. Für beide Ansichten gibt es valide Gründe.

Ich könnte mir allerdings vorstellen (kann's leider mangels RPI nicht prüfen), dass telerising.minimal nicht die Probleme beim Umstieg von RPI 4 auf 5 hat, denn die Binaries da drin werden explizit für arm64 gebaut. Sicher sagen kann man aber auch das nicht. Denn mit arm (32/64) sind die Architekturen und ihre Eigenheiten gefühlt deutlich komplexer und weniger tolerant geworden.

Hat schon einer telerising.minimal auf nem RPI 5 ohne die o.g. Anpassung zum Laufen bekommen?

ProdiG Ja gut, das erklärt das auch. Wenn Du etwas als Volume (eine Datei, wie in diesem Fall, oder Ordner) in Docker reingibst, dann muss das halt auch existieren. Der einfachste Weg dürfte sein auf dem Hostsystem folgendes auszuführen:

echo "Europe/Berlin" > /etc/timezone

timezone auch?

Gibt es denn auf deinem rpi /etc/timezone und /etc/localtime, also auf dem rpi direkt?

ProdiG Wie sieht denn jetzt Deine Zeile zum Starten des Containers genau aus?

ProdiG kann ich sonst vielleicht helfen was meinen container angeht? Wenn der Fix von wodkab läuft dann hat sich scheinbar das standard-alignment des rpi5 dahingehend geändert, dass es jetzt inkompatibel zu armv7 ist, was 32 Bit entspricht. Hatte mich ehrlich gesagt schon länger gewundert, warum das überhaupt geht auf einem 64 Bit rpi...

OK, gut - dann push ich das und ab der nächsten Version von easy4me nimmt er dann wieder das aktuelle Nuitka etc

talentfrei kannst Du mal, sofern möglich, von meinem Container das tag "debug" probieren bitte? Bei mir läuft das und und wäre mit der aktuellen Nuitka-Version gebaut...

Was Nuitka angeht find ich dann zwar die Reaktion trotzdem blöd, aber inhaltlich ist sie halt leider richtig: es gibt halt unter Linux einfach nicht wirklich das, was wir standalone nennen würden

OK, dann liegt es definitiv daran, dass libz.1.so auf deinem System vorhanden ist, im docker (da scratch) aber natürlich nur dann, wenn ich es reinkopiere unabhängig von der binary. Vorher hat Nuitka es in die binary reingebaut.

Starfoxfs bei dir ging die erste standalone binary 0.11.6 neulich aber auch nicht, oder? Und wenn ja: meckerte er über libz.1.so?

Starfoxfs Du benutzt nur die Binary, nicht docker, korrekt? talentfrei Du docker?

Naja, ich hab mich halt an ein bereits geschlossenes Ticket rangehängt wo jemand das gleiche Problem mit Binaries hatte die er unter Android hat laufen lassen. Da kam dann die Rückmeldung, dass das aufgrund der oben genannten Problematik gewollt ist um Konflikte mit dem Hostsystem zu vermeiden. Problem ist halt, das unter Linux "Standalone" eben nicht wirklich standalone ist (und das auch nicht wirklich geht). Das verstehe ich auch.

Von Scratch wollte er dann alledings nichts hören, sei ja kein Betriebssystem, und schon gar nicht davon, dass ich aktuell da libs von Hand mit reinpacke. Hatte ihm noch ne Frage beantwortet und dann kam nur die Aussage, dass das nutzen bereits geschlossener Tickets ein direkter Blockgrund ist und er hätte schon Zeit inverstiert obwohl er mit meiner Problematik in seinen Augen nichts zu tun hat.

Ich versteh das auch alles, fand die Reaktion aber mehr als unangemessen. Und Docker Scratch ist halt insbesondere für Standalone Binaries gedacht - daher finde ich den Usecase eigentlich valide...

Hm, also der Entwickler von Nuitka war jetzt nicht sonderlich erfreut über unseren Austausch wie es scheint.

Hab das Problem inzwischen gefunden und bin im Austausch mit Nuitka. Libz wird bewusst ab 1.9 nicht mehr mit reingebaut, da eigentlich alle Distros damit kommen, was dann reichen würde und libz eigentlich immer hochgradig distroabhängig ist und mehrere libz häufig zu Problemen führen.

Blöd nur, weil scratch, worauf mein Container basiert, halt komplett nackt kommt, also auch ohne libz.

Muss mal überlegen, was ich damit anfange...

Die binaries selbst hätten aber laufen sollen, also ohne docker

Die 0.11.6 läuft bei mir, scheint also wirklich ein Problem mit Nuitka 1.9.x zu geben. Ich werde das mal beobachten und evtl. noch ein paar Builds mit 0.11.6-debug machen die dann hoffentlich auch nicht automatisch "latest" werden...