Beiträge von dlueth

    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 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...

    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...

    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

    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...