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:
Beiträge von dlueth
-
-
-
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...
-
Starfoxfs und talentfrei GitHub baut gerade nochmal die 0.11. - allerdings muss ich zugeben keinen wirklichen Grund gefunden zu haben für den Fehler mit libz. Da es aber seit dem letzten Release eine neue minor von Nuitka (1.9.x) gegeben hat (was aus dem python Code ein Binary macht) wo im Changelog explizit libz erwähnt wirdhabe ich jetzt mal einfach eine 1.8er Version davon forciert. Ich checke auch nochmal bei mir, wenn der Build durch ist...
-
talentfrei Nein, hab ich nicht. Aber damit ich lokal bauen kann muss ich leider auch pushen in den Docker-Hub, das ist aktuell auch das "latest" und die darunter auftauchen 0.11.3 (aber ist nicht wirklich 0.11.3, funktioniert allerdings nicht). 0.11.6 konnte zwar gebaut werden, läuft aber aktuell noch nicht. Bin dran, aber es weigert sich hartnäckig...
Die letzte funktionierende Version ist die 0.11.5 aktuell
-
Achtung: die Version 0.11.6 startet nicht, es tritt folgender Fehler auf
Code
Alles anzeigenImportError: libz.so.1: cannot open shared object file: No such file or directory Traceback (most recent call last): File "//telerising.py", line 1, in <module> File "//app/main.py", line 1, in <module app.main> File "//flask/__init__.py", line 5, in <module flask> File "//flask/json/__init__.py", line 6, in <module flask.json> File "//flask/globals.py", line 6, in <module flask.globals> File "//werkzeug/__init__.py", line 5, in <module werkzeug> File "//werkzeug/serving.py", line 27, in <module werkzeug.serving> File "//http/server.py", line 92, in <module> File "//email/utils.py", line 40, in <module> File "//email/charset.py", line 14, in <module> File "//email/base64mime.py", line 37, in <module> File "//base64.py", line 11, in <module>
easy4me Hast Du evtl. eine Idee? Ich vermute die libz.so.1 ist irgendwie neu als dependency hinzugekommen - aber warum?
Ich schau es mir an so schnell es geht...
-
0.11.6 wurde automatisch gebaut
-