F-Droid-Build-Server kann wegen veralteter CPUs keine aktuellen Android-Apps mehr bauen

 (news.ycombinator.com)
1 Punkte von GN⁺ 2025-08-14 | 1 Kommentare | Auf WhatsApp teilen
  • Beim F-Droid-Build-Server ist eine Situation entstanden, in der wegen veralteter CPUs aktuelle Android-Apps nicht mehr gebaut werden können
  • Er unterstützt die in modernen mobilen Apps benötigten erweiterten Befehlssätze wie ARM und x86-64 nicht
  • Upgrades und Austausch der Server sind nötig, stoßen aber auf Kosten- und Infrastrukturgrenzen
  • Entwickler äußern Sorgen über die Nachhaltigkeit von F-Droid und seine technische Aktualität
  • Als Alternativen werden Cloud-basierte Builds sowie Spenden von Server-Ressourcen diskutiert

Überblick

  • F-Droid ist ein inoffizieller Store für Android-Open-Source-Apps, der Apps verteilt, indem er den Quellcode direkt baut
  • Kürzlich stellte sich heraus, dass die Build-Server die von aktuellen Android-Apps verlangten CPU-Befehlssätze nicht unterstützen, sodass für einige Apps keine Builds mehr bereitgestellt werden können

Technische Grenzen der Build-Server

  • Die alten CPUs unterstützen die für App-Builds nötigen neuen ARM- und x86-64-Befehle nicht
  • Durch diese Einschränkung können moderne Apps mit Performance-Optimierungen oder Apps mit aktuellen Bibliotheken nicht als Build-Artefakte bereitgestellt werden
  • Auch moderne Sprachen wie Python und Kotlin sowie aktuelle Build-Tools wie Gradle verlangen häufig neuere CPU-Umgebungen

Sorgen und Diskussionen in der Community

  • Entwickler und Nutzer äußern Besorgnis über die anhaltende Verschlechterung der App-Qualität bei F-Droid und Berichte über fehlgeschlagene Builds
  • Ein Infrastruktur-Upgrade ist nötig, doch finanzielle Grenzen und fehlendes Personal für die Server-Verwaltung treten deutlich hervor

Alternativen und Lösungsansätze

  • Diskutiert werden verschiedene Ansätze, etwa der Betrieb von Build-Servern in einer Cloud-Umgebung oder gemeinschaftlich gespendete Server-Ressourcen
  • Das F-Droid-Team hat erklärt, das Problem mithilfe von externer Unterstützung und neuer Hardware lösen zu wollen

Fazit

  • Der Wert von F-Droid und seine Bedeutung für die Unterstützung des Open-Source-Ökosystems bleiben hoch
  • Allerdings sind Innovationen bei der Infrastruktur und laufende Wartung unerlässlich, um mit modernen App-Trends Schritt zu halten

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-08-14
Hacker-News-Kommentare

  • Das bedeutet, dass ihre Server wirklich sehr alt sind, auf einem Niveau ohne Unterstützung für x86-64-v2; man denkt dabei fast an Server aus der Intel-Core-2-Duo-Ära.
    Siehe auch diesen Überblick zum x86-64-v2-Mikroarchitektur-Level in Red Hat Enterprise Linux 9.
    Wenn man auf einen Consumer-EPYC-CPU wechseln würde, dürfte die Serverleistung deutlich steigen.
    Ich wollte tatsächlich spenden, aber es waren bereits noch 80.000 $ übrig.
    Wenn man bedenkt, dass das Jahresbudget 17.000 $ beträgt, würde selbst der Kauf eines aktuellen Zen4- oder Zen5-mATX-Consumer-EPYC-Servers für 2.000 bis 3.000 $ noch ins Budget passen.
    Falls es wirklich mehrere stark veraltete Server sind, könnte ein einzelner Zen5-Server gleich mehrere ersetzen und dabei viel Strom und Platz sparen.
    Siehe auch den Budgetstatus von F-Droid.
    Die Librapay-Spenden scheinen noch nicht enthalten zu sein.
    Link zu den Librapay-Spenden

    • Es muss nicht zwingend nur an alten Servern liegen. Aus unserer Erfahrung mit Virtualisierungsplattformen heraus hatten wir nach einem Upgrade der VMs eines externen Anbieters zwar auf der CPU x86_64v2 + AES als unterstützt exponiert, trotzdem liefen einige Dienste nicht.
      Die Mindestanforderung lautete „Pentium und Celeron“, also dachten wir, das reiche aus.
      Tatsächlich verwendete aber einer der Dienste Instruktionen, die nur auf v3- oder v4-CPUs unterstützt werden, und stellte deshalb den Betrieb ein.
      Nachdem wir die exponierten CPU-Einstellungen geändert hatten, lief alles wieder normal.
      Es kann also auch sein, dass die Serverleistung an sich ausreicht, aber eine Fehlkonfiguration vorliegt, oder dass das Binary höhere Anforderungen hat als angegeben, oder dass ein anderer Faktor dahintersteckt.
    • 2.000 bis 3.000 $ entsprechen in Wahrheit gerade einmal dem Preis einer einfachen Threadripper-Standard-CPU; für einen kompletten EPYC-Server reicht das wohl nicht.
    • Vielleicht booten die Server ja mit Coreboot oder Libreboot.
    • Ich frage mich, ob Linux so alte Hardware zu diesem Zeitpunkt überhaupt noch offiziell unterstützt.
      Die cmpxchg16b-Instruktion ist noch gar nicht so alt und gilt inzwischen als Mindestvoraussetzung.
    • Selbst wenn nicht mehr viel Geld übrig wäre, würde ich weiterhin zu Spenden raten.
      Verglichen mit der Zeit und Arbeit, die Freiwillige in die Pflege des Systems stecken, sind 80.000 £ wirklich nicht viel.
      Ich habe gehört, dass eine Modernisierung der Infrastruktur nötig ist, aber das erfordert größere Investitionen.
      Mit mehr finanzieller Reserve hätte man vermutlich auch mehr Vertrauen, diese Investitionen tatsächlich zu tätigen.
      Neben Server-Upgrades gibt es noch viele weitere Baustellen.

  • Die aktuelle Situation wirkt ziemlich besorgniserregend.
    F-Droid ist nach Google derzeit vermutlich der größte Android-App-Store, deshalb halte ich ihn für umso wichtiger.
    Ich frage mich, ob es Pläne zur Behebung dieses Problems gibt, wann F-Droid die Server aufrüsten könnte oder ob Google diese Pflichtanforderung vielleicht doch zurücknimmt, auch wenn Letzteres eher unwahrscheinlich erscheint.

    • Wenn man bedenkt, dass F-Droid ein von Freiwilligen getragenes Community-Projekt ist, verstehe ich die Sorge. Gerade weil insbesondere EU-Länder auf Open-Source-Software umsteigen, wäre öffentliche Finanzierung für Projekte wie F-Droid wünschenswert.
    • Wenn F-Droid wichtig ist, sollte man auch direkt für die Anschaffung moderner Build-Server spenden.
    • Was die Möglichkeit angeht, dass Google die Anforderung zurücknimmt: Es gab schon 2021 ein ähnliches Problem. Damals verlangte das Gradle Plugin 4.1.0 die SSSE3-Instruktion, was zu Problemen führte.
      Behoben wurde das in Gradle Plugin 4.2.0-rc01 / Gradle 7.0.0 alpha 9.
      Dazu gibt es auch ein tatsächliches Ticket im Issue-Tracker.
    • Ich bin skeptisch, was die Aussage angeht, F-Droid sei der größte Android-Store außerhalb von Google.
      Meiner Meinung nach wäre es nicht einmal in den Top 10.
    • Nachdem ich die Erklärung gehört habe, dass „Googles Build-Tools nicht aus dem Source gebaut werden, sondern separat optimiert und als Binary ausgeliefert werden“, stimme ich nicht zu, dass daraus automatisch folgt, dass die Server aufgerüstet werden müssen.

  • Ich frage mich, warum man aapt2 nicht einfach passend zum Zielsystem neu baut.
    Der Source ist verfügbar.
    Ort des aapt2-Sourcecodes

    • Ich würde gern wissen, ob du jemals tatsächlich AOSP gebaut hast.
      Da stecken extrem viele Binaries drin, und als ich versucht habe, einige davon aus dem Source neu zu bauen, war das Build-System so kaputt, dass ich sofort aufgegeben habe.
    • QEMU-CPU-Emulation in Docker zu verwenden ist wartungstechnisch viel einfacher, als aapt2 jedes Mal neu zu kompilieren.
      So kann man künftige Binary-Updates automatisch abfangen, statt jedes neue Binary erneut patchen zu müssen.

  • Ich teile mal den Wikipedia-Artikel zu Streaming SIMD Extensions (SSSE3).
    Selbst mein alter Desktop unterstützte diese Instruktion, und ich habe ihn fast zehn Jahre lang genutzt.
    Umso überraschender ist es, dass im Sourcecode nicht einmal ein Fallback-Pfad ohne Assembler bereitgestellt wurde.

    • Auf die Frage „Warum gibt es nicht einmal einen Fallback-Pfad ohne Assembler?“ würde ich sagen, dass es wahrscheinlich gar kein Problem mit handgeschriebenem Assembler ist.
      Wahrscheinlicher ist, dass der Compiler schlicht mit Ziel x86_64-v2 gebaut wurde.
      RHEL 9 wurde ebenfalls mit solchen Optionen gebaut, und in RHEL 10 geht es auf x86_64-v3 hoch, womit dann auch AVX unterstützt wird.
    • Wenn man sich das Issue ansieht, scheint der Builder ein Opteron-G3-(K10)-System zu sein.
      AMD-10h-Wiki-Link
    • Dass es keinen Fallback-Pfad gibt, liegt an fehlender Testhardware.
      Praktisch gibt es keine Hardware mehr, auf der man das sinnvoll testen kann; übrig sind nur alte und langsame Geräte.
    • Wenn jemand einen alten Desktop spenden würde, wäre F-Droid vermutlich erfreut.

  • Ganz nachvollziehen kann ich das nicht.
    Gradle und aapt2 sind Open Source, und wenn man die Toolchain wie bei buildroot oder openwrt selbst kompiliert, erhält man ein deutlich vorhersagbareres Ergebnis.
    Auch F-Droid könnte die komplette Toolchain selbst aus dem Source bauen und müsste dann keine Binary-Versionen von Gradle oder aapt2 mit nicht unterstützten Instruktionen verwenden.

    • Tatsächlich ist man aber wohl weiterhin auf die von Google bereitgestellten SDK-Binaries angewiesen.
    • Ich halte diesen Ansatz grundsätzlich für vernünftig, aber Gradle lädt seinerseits Abhängigkeiten wie vorgebaute Java-Bibliotheken herunter und verwendet sie.
      Darunter sind auch native Binaries, und anders als bei buildroot oder Linux-Distributionen gibt es keine Metadaten darüber, wie jede einzelne Bibliothek gebaut wird.
      Außerdem unterscheiden sich die Build-Prozesse innerhalb des Gradle-Ökosystems von Bibliothek zu Bibliothek erheblich und sind nicht standardisiert. Deshalb ist es sehr mühsam und schwierig, das gesamte System selbst aus dem Source zu rekonstruieren.

  • Es heißt auch, Google habe das Problem upstream bereits behoben.
    Siehe dieses Issue.
    Wie schnell das gelöst wird, ist unklar, aber auch wenn der Thread keinen direkten Beleg für eine tatsächliche Behebung liefert, wirkt das zumindest etwas beruhigend.

    • Tatsächlich ist es noch nicht behoben.
      In dem verlinkten Thread wurde eine Tippfehlerkorrektur („mas fixed“ → „was fixed“) fälschlich als Hinweis verstanden, dass dieses Issue bereits gelöst sei.
      Behoben wurde in Wirklichkeit ein ähnliches Problem aus einigen Jahren zuvor.
      Siehe dazu den Google Issue Tracker.
    • Dieses Grundproblem ist unter Entwicklern bis heute noch nicht wirklich bekannt.

  • Wenn man bedenkt, dass sse4.1 bereits 2011 eingeführt wurde, ist es schon seltsam, dass solche alten Server noch in Betrieb sind.
    Mit einer modernen CPU ließe sich dieselbe Arbeit mit nur einem Bruchteil des Stromverbrauchs erledigen; wirtschaftlich erscheint es daher ebenfalls wenig sinnvoll, an alter Hardware festzuhalten.
    Weiß jemand Näheres über Anzahl oder Spezifikationen der Build-Server?

    • Zu der Aussage, man müsse wegen des geringeren Stromverbrauchs moderner CPUs schnell aufrüsten: Wenn eine 500-W-CPU bei 8.760 Stunden im Jahr das ganze Jahr unter Volllast liefe, lägen die Stromkosten bei 550 $.
      Selbst wenn man das halbiert, entspricht das nur 10 % des Preises eines neuen Rechners; bis sich die Investition amortisiert, vergehen also zehn Jahre.
      Hinzu kommt, dass ein Upgrade eine Investitionsausgabe ist, während Stromkosten Betriebsausgaben sind.
      Beleg zu US-Strompreisen
    • sse4.1 wurde erstmals im November 2007 mit Intel Penryn eingeführt; AMD unterstützte es erst ab Bulldozer Mitte 2011.
      Bulldozer brachte zwar diverse zusätzliche Instruktionen wie AVX und FMA, aber ältere Opterons waren in der Praxis oft schneller als Bulldozer, sodass es bis zum Erscheinen von EPYC Mitte 2017 wenig Anreiz für ein Upgrade gab.
      Dass in vielen Paketen inzwischen sse4.1 oder höher vorausgesetzt wird, liegt daran, dass auf alten CPUs der Overhead für Dinge wie Verzweigungen bei SIMD-Parallelisierung hoch ist.
    • Die eigentliche Antwort könnte auch schlicht lauten: weil man Dual-Socket-AMD-Boards ohne ME/PSP und mit Open Firmware verwenden kann, etwa das KGPE-D16.
    • Mit Servern kenne ich mich nicht gut aus, aber im Desktop-Bereich sieht man alte Hardware tatsächlich noch häufig.
      Alte PCs aus den 2000ern reichten für alltägliche Aufgaben wie Web-Browsing lange völlig aus, doch mit der Zeit verlangten Programme neue Instruktionen und machten sie nach und nach unbrauchbar.
      Am Ende verlangte sogar Firefox neue Instruktionssätze, sodass ich schließlich einen eigentlich noch funktionierenden Desktop entsorgen musste.
    • Ich vermute, dass alte CPUs wegen freier Firmware wie Canoeboot oder GNU Boot verwendet werden.
      Allerdings lassen sich auf dem KGPE-D16 auch CPUs mit SSE4.2-Unterstützung einsetzen, daher bin ich mir über den genauen Grund nicht sicher.

  • Bei den neuen aapt2-Binaries von Google (AGP 8.12.0) überrascht mich, dass F-Droid als Projekt so großen Wert auf Schutz und Isolierung der Build-Umgebung legt, dann aber ausgerechnet Upstream-Binaries übernimmt, statt alles aus dem Source zu bauen.

    • Dazu kommt, dass es bis vor relativ kurzer Zeit keine aktuelle frei verfügbare Software-Builds des Android SDK gab.
      Wer Android-Apps bauen will, ist im Grunde auf nicht freie Binaries von Google angewiesen.
      Siehe dazu diesen Forenbeitrag.

  • Zusammenstellung von Referenzlinks
    F-Droid-Admin-Issue
    Catima-App-Issue
    MBCompass-Issue

    • Wenn man den Catima-Thread liest, bleibt stark der Eindruck zurück, dass es extrem schwierig ist, mit der F-Droid-Community zusammenzuarbeiten.
      Ein Mitglied sagte dazu: „Wie bei F-Droid immer werden unsere Stimmen ignoriert. Hätte es Hoffnung gegeben, durch Diskussionen über Lösungen F-Droid zu verbessern, wäre ich nach all der investierten Zeit und Energie nicht frustriert gegangen.“

  • Die F-Droid-Server sind wohl wirklich uralt.
    Selbst wenn man auf einer völlig anderen Architektur x86_64 emuliert, dürfte das noch Leistungsgewinne bringen.
    Man muss hier nicht einmal mit OSS-Argumenten kommen.
    Wenn einen geschlossene Firmware nicht stört, gibt es viele günstigere und modernere x86-Serveroptionen.

    • Bei der Aussage „Die Server sind wirklich uralt“ erwartet man fast einen Witz.
      Dank der Popkultur denkt man sofort an Sprüche wie: „Der Server ist so alt, dass er mit Benjamin Franklin im Kindergarten war.“