Le serveur de build F-Droid ne peut plus compiler les applications Android récentes à cause d’un CPU ancien

• Le serveur de build de F-Droid n’est plus en mesure de compiler des applications Android récentes à cause d’un CPU ancien
• Il ne prend pas en charge les jeux d’instructions avancés requis par les applications mobiles modernes sur ARM, x86-64, etc.
• Une mise à niveau et un remplacement des serveurs sont nécessaires, mais se heurtent aux limites de coût et d’infrastructure
• Les développeurs expriment des inquiétudes quant à la pérennité de F-Droid et à son niveau de modernité technique
• Des alternatives comme des builds basés sur le cloud et des dons de ressources serveur sont en cours de discussion

---

Aperçu

• F-Droid est une boutique non officielle d’applications open source pour Android, qui distribue les applications après avoir directement compilé leur code source
• Récemment, ses serveurs de build ne prenant pas en charge les jeux d’instructions CPU exigés par les applications Android récentes, il n’est plus possible de fournir les builds de certaines d’entre elles

Limites techniques des serveurs de build

• Les anciens CPU ne prennent pas en charge les nouvelles instructions ARM et x86-64 nécessaires à la compilation des applications
• À cause de cette limitation, il devient impossible de fournir des fichiers compilés pour des applications modernes optimisées en performances ou utilisant des bibliothèques récentes
• Des langages récents comme Python et Kotlin, ainsi que des outils de build modernes comme Gradle, exigent eux aussi souvent un environnement CPU récent

Inquiétudes et discussions dans la communauté

• Développeurs et utilisateurs font part de leurs inquiétudes face à la dégradation continue de la qualité des applications sur F-Droid et aux échecs de compilation signalés
• Une mise à niveau de l’infrastructure est nécessaire, mais les contraintes financières et le manque de personnel pour administrer les serveurs sont mis en avant

Recherche d’alternatives et de solutions

• Différentes pistes sont discutées, comme l’exploitation des serveurs de build dans un environnement cloud ou des dons communautaires de ressources serveur
• L’équipe de F-Droid a exprimé sa volonté de résoudre le problème grâce à un soutien externe et à l’acquisition de nouveau matériel

Conclusion

• La valeur de F-Droid et son rôle de soutien à l’écosystème open source restent importants
• Mais des efforts d’innovation de l’infrastructure et de maintenance adaptés aux tendances actuelles des applications sont indispensables

[GN⁺]

Réactions sur Hacker News

• Cela signifie que leurs serveurs sont vraiment très anciens, au point de ne pas prendre en charge x86-64-v2, ce qui fait penser à des serveurs de l’époque des Intel Core 2 Duo
  Voir aussi cet article récapitulatif sur le niveau de microarchitecture x86-64-v2 de Red Hat Enterprise Linux 9
  En passant à des CPU Epyc grand public, les performances des serveurs seraient sans doute bien meilleures
  J’avais justement pensé à faire un don, mais il leur restait déjà 80 000 $
  Étant donné que leur budget annuel est de 17 000 $, même en achetant un serveur Epyc grand public mATX récent en Zen4 ou Zen5 pour 2 000 à 3 000 dollars, cela resterait dans le budget
  S’il y a vraiment plusieurs serveurs vieillissants, une seule machine Zen5 pourrait en remplacer plusieurs, tout en économisant beaucoup d’électricité et d’espace
  Voir aussi l’état du budget de F-Droid
  Il semble que les dons via Librapay ne soient pas encore comptabilisés
  Lien de don Librapay

  • Ce n’est pas forcément seulement une question d’ancienneté des serveurs. D’après notre expérience avec notre plateforme de virtualisation, après une mise à niveau d’une VM chez un fournisseur externe, le CPU exposé annonçait bien la prise en charge de x86_64v2 + AES, mais certains services ne démarraient toujours pas
    L’exigence minimale était « Pentium et Celeron », donc on pensait être tranquilles
    En réalité, l’un des services utilisait une instruction prise en charge uniquement sur des CPU v3 ou v4, ce qui l’a fait tomber en panne
    Une fois les paramètres du CPU exposé modifiés, tout a refonctionné normalement
    Donc il est possible que le serveur ait en réalité les performances nécessaires, mais qu’il y ait une erreur de configuration, ou qu’un binaire exige plus que ce qu’il annonce explicitement, ou un autre problème du même genre
  • 2 000 à 3 000 dollars, en réalité, c’est à peine le prix d’un Threadripper d’entrée de gamme seul, donc ça ne suffira probablement pas pour acheter un serveur Epyc complet
  • Il est aussi possible que le serveur démarre avec Coreboot ou Libreboot
  • Je me demande même si Linux prend encore officiellement en charge un matériel aussi ancien aujourd’hui
    L’instruction cmpxchg16b n’est pas si récente, et elle est désormais généralement considérée comme obligatoire
  • Même s’il leur reste un peu d’argent, je recommanderais quand même de faire un don
    80 000 £, c’est vraiment peu au regard du temps et des efforts que des bénévoles consacrent à maintenir ce système
    J’ai entendu dire qu’une modernisation de l’infrastructure était nécessaire, mais qu’elle demanderait un investissement important
    Avec une trésorerie plus confortable, ils auraient sans doute davantage confiance pour investir
    Il y a d’autres problèmes à régler en plus de la mise à niveau des serveurs

• Je trouve la situation assez préoccupante
  F-Droid est sans doute aujourd’hui le plus grand app store Android en dehors de Google, ce qui le rend d’autant plus important
  Je me demande s’il existe un plan pour résoudre ce problème, quand F-Droid pourrait mettre à niveau ses serveurs, ou si Google pourrait revenir sur cette exigence obligatoire, même si ce dernier scénario me semble peu probable

  • Étant donné que F-Droid est un projet communautaire géré par des bénévoles, cette inquiétude est compréhensible, mais j’aimerais qu’il y ait un financement public pour des projets comme F-Droid, surtout au moment où des pays de l’UE migrent vers des logiciels open source
  • Si F-Droid est important, il faut aussi envisager de faire directement un don pour l’achat de serveurs de build récents
  • Sur la possibilité que Google retire cette exigence, un problème similaire s’était déjà produit en 2021, lorsque Gradle Plugin 4.1.0 exigeait l’instruction SSSE3
    Le problème a été corrigé dans Gradle Plugin 4.2.0-rc01 / Gradle 7.0.0 alpha 9
    Il reste d’ailleurs une trace du ticket
  • Je suis sceptique sur l’idée que F-Droid soit le plus grand store Android hors Google
    À mon avis, il n’entrerait même pas dans le top 10
  • Après avoir entendu l’explication selon laquelle « les outils de build de Google ne se compilent pas depuis les sources, ils sont publiés en binaire avec des optimisations spécifiques », je ne suis pas d’accord avec la conclusion selon laquelle il faut forcément mettre à niveau les serveurs

• Je me demande pourquoi ils ne recompilent pas simplement aapt2 pour la cible
  Le code source est disponible
  Emplacement des sources de aapt2

  • J’aimerais demander si vous avez déjà réellement compilé AOSP
    Il y a énormément de binaires, et quand j’ai essayé d’en recompiler certains à partir des sources, le système de build était tellement cassé que j’ai abandonné immédiatement
  • Utiliser l’émulation CPU QEMU dans Docker est bien plus simple à maintenir que de recompiler aapt2 à la main à chaque fois
    Cela permet aussi de suivre automatiquement les mises à jour des binaires, sans devoir repatcher chaque nouveau binaire publié

• Je partage la page Wikipédia sur Streaming SIMD Extensions (SSSE3)
  Même mon vieux desktop prenait en charge cette instruction, et je l’ai utilisé pendant près de dix ans
  Je trouve donc surprenant qu’ils n’aient même pas prévu de chemin de repli non assembleur dans le code source

  • À la remarque « c’est étrange qu’il n’y ait même pas de chemin de repli sans assembleur », je pense qu’il ne s’agit probablement pas d’un problème de code assembleur écrit à la main
    Le plus probable est que le compilateur ait été utilisé avec une cible x86_64-v2
    RHEL 9 a été compilé ainsi lui aussi, et RHEL 10 montera à x86_64-v3, avec prise en charge d’AVX
  • En regardant l’incident, le builder semble être basé sur un Opteron G3 (K10)
    Lien Wikipédia AMD 10h
  • L’absence de chemin de repli vient du manque de matériel de test
    En pratique, personne n’a vraiment le matériel nécessaire pour tester cela, à part des machines anciennes et lentes
  • Si quelqu’un donnait un vieux desktop, F-Droid en serait probablement ravi

• Je ne comprends pas complètement
  gradle et aapt2 sont open source, et si on compilait soi-même toute la toolchain comme dans buildroot ou openwrt, on obtiendrait un résultat plus prévisible
  F-Droid pourrait de la même manière reconstruire toute la toolchain depuis les sources et éviter ainsi d’utiliser des binaires gradle ou aapt2 contenant des instructions non prises en charge

  • En pratique, ils sont encore obligés d’utiliser les binaires SDK fournis par Google
  • L’idée me paraît valable, mais gradle télécharge et utilise aussi de son côté des dépendances comme des bibliothèques Java précompilées
    Certaines embarquent des binaires natifs, et contrairement à buildroot ou aux distributions Linux, il n’existe pas de métadonnées décrivant la manière dont chaque bibliothèque a été compilée
    En plus, le processus de build varie d’une bibliothèque de l’écosystème Gradle à l’autre, sans vraie standardisation, donc tout reconstruire à partir des sources serait un travail considérable et compliqué

• Certains disent que Google a déjà corrigé le problème en amont
  Voir ce lien vers l’incident
  Il est difficile de savoir à quelle vitesse cela sera résolu, mais le fil donne quand même un peu d’espoir, même sans preuve directe qu’un correctif a bien été appliqué

  • En réalité, ce n’est pas encore corrigé
    Dans le fil lié ci-dessus, quelqu’un a pris une correction de faute de frappe (« mas fixed » → « was fixed ») pour la résolution de l’incident actuel
    Ce qui a été corrigé, c’est un problème similaire plus ancien, datant de plusieurs années
    Voir le Google Issue Tracker
  • Ce problème de fond reste encore mal connu des développeurs

• Quand on pense que sse4.1 est une instruction introduite en 2011, c’est étonnant que des serveurs aussi anciens soient encore en service
  Avec des CPU récents, on pourrait faire le même travail avec une fraction de la consommation électrique, donc économiquement aussi j’ai du mal à comprendre qu’on continue à utiliser un matériel aussi vieux
  Si quelqu’un connaît le nombre ou les spécifications des serveurs de build, ça m’intéresserait

  • À l’argument selon lequel il faudrait mettre à niveau rapidement parce que des CPU récents feraient le même travail pour une fraction de la facture électrique, une réponse fait remarquer que sur 8 760 heures annuelles, même un CPU de 500 W tournant à pleine charge toute l’année ne coûterait qu’environ 550 $ d’électricité
    Même en divisant ce coût par deux, cela ne représente qu’environ 10 % du prix d’un ordinateur neuf, ce qui ferait un amortissement sur dix ans
    Il faut aussi distinguer les dépenses d’investissement des dépenses d’exploitation
    Source sur les tarifs de l’électricité aux États-Unis
  • sse4.1 a d’abord été introduit par Intel Penryn en novembre 2007, et AMD ne l’a pris en charge qu’avec Bulldozer, à la mi-2011
    Bulldozer ajoutait aussi diverses instructions comme AVX et FMA, mais dans de nombreux cas les anciens Opteron restaient en pratique plus rapides que Bulldozer, donc l’incitation à mettre à niveau est restée faible jusqu’à l’arrivée d’Epyc, à la mi-2017
    Si beaucoup de paquets exigent aujourd’hui sse4.1 ou plus, c’est aussi parce que sur les vieux CPU, la surcharge liée aux branchements conditionnels et autres opérations réduit l’intérêt du parallélisme SIMD
  • La vraie réponse est peut-être simplement qu’on peut utiliser des cartes mères AMD bi-socket sans firmware propriétaire ni ME/PSP, comme la KGPE-D16
  • Je ne connais pas bien le monde des serveurs, mais on voit souvent ce genre de vieux matériel côté desktop
    Les vieux PC des années 2000 restaient suffisants pour des usages ordinaires comme la navigation web, puis avec le temps les logiciels ont commencé à exiger de nouvelles instructions, ce qui les a progressivement rendus inutiles
    Même Firefox a fini par exiger un jeu d’instructions plus récent, et j’ai moi-même dû abandonner un desktop pourtant encore parfaitement fonctionnel
  • Je pense que l’usage de vieux CPU est sans doute lié à un firmware libre comme Canoeboot ou GNU Boot
    Cela dit, la carte KGPE-D16 peut aussi accueillir des CPU compatibles SSE4.2, donc je ne connais pas la raison exacte

• À propos du nouveau binaire aapt2 de Google (AGP 8.12.0), je trouve étonnant que F-Droid, qui accorde énormément d’importance à la protection et à l’isolation de son environnement de build, récupère malgré tout les binaires upstream au lieu de tout compiler depuis les sources

  • À ce sujet, il n’existe toujours pas, même assez récemment, de build libre et à jour du SDK Android
    Pour développer des applications Android, on dépend encore fondamentalement de binaires non libres fournis par Google
    Voir ce billet de forum connexe

• Récapitulatif de liens utiles
  Incident d’administration F-Droid
  Incident de l’application Catima
  Incident MBCompass

  • En lisant le fil Catima, on garde vraiment l’impression qu’il est très difficile de travailler avec la communauté F-Droid
    Un membre dit ceci : « Comme toujours avec F-Droid, nos voix sont systématiquement ignorées. S’il y avait eu le moindre espoir de discuter de solutions pour améliorer F-Droid, je ne serais pas parti frustré après y avoir investi autant de temps et d’énergie. »

• Les serveurs de F-Droid semblent vraiment vétustes
  On en serait presque au point où émuler x86_64 sur une architecture complètement différente apporterait malgré tout un gain de performances
  On n’a même plus besoin d’invoquer un argumentaire OSS pour le dire
  Et si les firmwares propriétaires ne sont pas un sujet, il existe beaucoup d’options de serveurs x86 plus récentes et moins chères

  • Quand j’entends « les serveurs sont vraiment vétustes », je m’attends presque à une blague
    Avec la culture populaire, ça évoque des formules du genre « ce serveur est si vieux qu’il était en maternelle avec Benjamin Franklin »