Static Binaries

Quote from perryflynn

Würde mich freuen, wenn Ihr das Ganze mal auf unterschiedlichen Plattformen testen könntet.

Keine riscv64-Binaries? (Ok, zugegeben, dafür habe ich auch nur eine emulierte Umgebung, bis es endlich passende Hardware für Homeoffices gibt …)

EDIT1: Versionsnummern im Dateinamen wären ggf. von Vorteil, sofern nicht gewährleistet ist, dass es sich immer um die aktuelle Upstream-Version handelt.

EDIT2: Aha, sie stehen in der info.txt-Datei, die niemand liest (der hier vor der Tastatur sitzt).

Erstmal Danke für Deine Arbeit!
Habe Dein rsync auf einem netcup Webhostingpaket ausprobiert. (Webhosting 8000)
Es läuft auch, aber leider erhalte ich jede Menge "failed to set permission Meldungen", weil Datei nicht vorhanden.
z.b.: rsync: [generator] failed to set permissions on "/backup/net/test/tmp/test.pdf": No such file or directory (2)
Und das, obwohl die Datei dann doch auf dem Zielserver vorhanden ist.
Hat jemand eine mögliche Erklärung hierfür?

Meistens liegt das an nicht kompatiblen Optionen.

Wie sehen deine aus?

Kann es sein, dass "/backup/net/test/tmp/" ein Filesystem verwendet, dass mit Linux Dateirechten nicht umgehen kann?

Quote from Olivetti

Meistens liegt das an nicht kompatiblen Optionen.

Wie sehen deine aus?

Meine Optionen: rsync -asv --rsync-path=~/myBin/rsync

Quote from frank_m

Kann es sein, dass "/backup/net/test/tmp/" ein Filesystem verwendet, dass mit Linux Dateirechten nicht umgehen kann?

Eher nicht, weil ich die Dateirechte manuell ja setzen kann.

wenn du -a weglässt und es dann funktioniert, hast du zwei inkompatible filesysteme.

hilfreich ist auch die verbosity aufzudrehen -vv -vvv

perryflynn: Ist geplant, die Binaries von Zeit zu Zeit aufzufrischen? (Nicht, dass meinerseits gerade ein dringender Bedarf bestünde, sondern weil mir selbst vorhin ins Auge fiel, dass es beispielsweise von jq schon die v1.7.1 gibt und ich beim "Herumspielen" mit Binaries dann gerne immer zunächst die neueste Version nutze.)

Schreit das nicht nach ner Github Pipeline?

Für curl gibt es bereits ein GitHub-Projekt (stunnel/static-curl), welches vom Funktionsumfang derzeit sogar über das Debian-/Ubuntu-Pendant hinausgeht; hier könnte man sich ggf. über einen Verweis Arbeit sparen (oder das dortige Build-Script forken).

Quote from perryflynn

Ob das mit den CPU Architekturen auf nem GitHub Actions Runner funktionieren würde, weiß ich nicht. Ich habe GitLab benutzt weil ich da mehr Erfahrung habe und eigene Runner betreibe.

Das geht mit QEMU auf manchen der GitHub Actions Runnern. So baue ich auch Docker images z. B. für ARM64.

Quote

Den Build Prozess auf GitHub Actions umbauen würde ich nicht unbedingt versuchen. Das klingt für mich nach etwas, was mehrere Tage dauern kann und nervig wird.

Oh ja, da hast du auf jeden Fall Recht. Zumal ich in den letzten Monaten persönlich auch immer wieder Probleme durch GitHub Actions bekommen habe. (So richtig ausgereift scheint das nicht zu sein und ich trauere GitLab da etwas hinterher.)

Quote

Dadurch das GitHub Actions nur 2000 Minuten kostenlose Runners bereit stellt, könnte die Pipeline 22 Mal komplett durchlaufen, bis dieses Limit erreicht ist.

Eventuell sogar weniger, weil auf meiner Pipeline vier Jobs parallel laufen und die Pipeline trotzdem 1,5 Stunden braucht wenn keine Caches da sind.

Das sollte doch schon längst kein Problem mehr sein oder? Mit den GitHub-hosted Actions Runnern gibt es bei öffentlichen Repos/Organisationen keine zeitliche Einschränkung mehr, soweit ich weiß. Ich habe diverse Repos, die alle auch größere Sachen in der CI laufen lassen; solange die Projekte öffentlich sind, wird da im "Billing" bei GitHub nichts angezeigt.