Beiträge von dlueth

Argh, sorry, ich sehe es gerade... Ich hatte in den arm64 & arm32/v7 Versionen in dem Script welches die benötigten Libs überträgt jeweils die libnss_files* vergessen. Die sind zuständig für die Namensauflösung innerhalb des Containers. Dann ist es auch klar, dass das nicht geht. Ich baue gerade neu, dauert aber ein paar Stunden.

Den Fehler kenne ich @talentfrei, aber eigentlich sollte der nicht kommen. Der amd64 Container läuft absolut sauber bei mir.

Hintergrund: ich hatte exakt diesen Fehler immer, wenn ich versucht habe anstatt BusyBox scratch zu benutzen für das Image. Grund dafür war eine fehlende /etc/nsswitch.conf die für die Namensauflösung des eigenen Hosts innerhalb des containers gebraucht wurde. Die ist nun aber im Container enthalten.

Wie sieht das ggf. bei anderen aus? Sonst gehe ich wieder zurück auf BusyBox.

@talentfrei was ist denn die Fehlermeldung und auf was für einem System läuft es bei dir? Laut docker Hub war der build vor dem aktuellen latest vor 3 Tagen, da war also alles richtig von meiner Seite aus

@toab90 Die Warnung kannst Du ignorieren, hab die Stelle gefunden. Beim Minimieren der Binary wird die Zeile die von easy dafür vorgesehen war, dass sie nicht kommt, wohl entfernt. Ich hab ihn mal gefragt ob er eine Idee hat warum. Hat aber keine Auswirkung auf die Funktion

Neue Version ist gepushed in den Docker Hub und läuft bei mir sauber auf Basis von, jetzt neu, Scratch. Daher auch nochmal etwas kleiner.

Also, ich baue gerade eh nochmal neu und pushe (jetzt auf Basis von Scratch und nicht mehr busybox-glibc) aber die letzte Version im Docker-Hub sollte die 0.9.0 sein. Wie updatest Du Deine Container @talentfrei? Docker zickt da auch gerne mal rum wenn man nur "latest" benutzt und macht kein Update

Ich schau gleich nochmal

Neue Version ist gepushed

Ja, wäre es und kommt - gerade etwas stressig kurz vor Weihnachten Neuer Build kommt so schnell wie möglich

@DeBaschdi Ja, nur Starfoxfs hatte ja schon gesagt, dass er Docker halt nicht will. Und vor dem Hintergrund klang das für mich so nach "nimm doch einfach das Binary für armhf" - und das geht halt zwar in Deinem Docker, aber nirgendwo anders, außer auf einem Debian-basierten armhf Rechner XD

@DeBaschdi aber Achtung. Die armhf binary direkt von easy läuft trotzdem nicht direkt in einem arm64 System

Zitat von Starfoxfs

Jep die PN funktioniert

Du hast eine PN - sag bescheid ob's läuft

@easy4me ich könnte dir auch mein Dockerfile geben + Support. Dann könntest Du amd64, arm32/v7 und arm64 in einem Rutsch und auf einem Rechner bauen und auch bei Dir im öffentlichen Repo hinterlegen?

Dann wurde das aber auf amd64 Debian gebaut, nicht arm64 - und das kann natürlich nicht laufen @Starfoxfs PN gehen bei Dir?

@Starfoxfs evtl könnte ich da auch einspringen, zumindest Mal zum Testen, und dir ein tgz bereitstellen. Das müsste doch eigentlich arm64 sein, oder?

Hm, blöd. Das nächtliche Autobuild musste ich deaktivieren leider für den Moment. Ich baue gerade die aktuelle Version von Hand und pushe sie.

Mir waren die doch einigermaßen harten Limits von GitHub Workflows nicht bewusst. Insgesamt hat man als Free-User 2000 Minuten pro Monat für Workflows, als normaler zahlender User auch nur 3000. Da hauen dann die 2h 40m - 3h 10m pro Build doch ganz gut rein XD.

@Starfoxfs Warum nimmst Du nicht Docker?

Ja, kannst Du ignorieren. Ich vermute da fliegt bei der Kompression via strip & upx irgendwas raus, was den normalen Output von easy via print unterdrückt und stattdessen den Default output durchlässt @toab90

Ich Versuch das noch genauer herauszufinden und wenn möglich zu beheben, ist aber nicht schlimm

@easy4me OK, ich schau mir das mal an und schick Dir ne PM dazu XD

Du hast anderes & wichtigeres zu tun

@easy4me Vielleicht können wir das auch noch automatisieren, wenn Du meine GitHub-Action bei Push auf Dein Repo triggerst? Würde zwar dauern, aber es wäre immerhin "schnellstmöglich"