Benoît Sibaud a écrit 9999 commentaires

C'est précisément ce que dit la dépêche.

La version suivante du composant la remplace d’ailleurs par un ajout de l'option :close_others, qui précisément « modifie l’héritage [des descripteurs de fichiers du processus parent] en fermant les non-standards (numéros 3 et plus grands) ».

Caurigé, merci.

Corrigé, merci. Probable conséquence de l'incident d'hier (cf dépêche en attente de publication)

Ajouté, merci.

La cause possible peut donc être un souci d'instabilité électrique, l'arrêt/extinction physique sur le serveur, un bug ou une faille logicielle, ou encore le redémarrage électrique via la carte d'administration. Cette cause n'est actuellement pas connue.

Visiblement il y a eu un hoquet dans l'alimentation électrique du serveur :

Thu Jun 26 2025 04:16:14    The system board PS1 PG Fail voltage is within range.   
Thu Jun 26 2025 04:16:09    The system board PS1 PG Fail voltage is outside of range.   
Thu Jun 26 2025 04:15:55    Power supply 1 fan is operating normally.   
Thu Jun 26 2025 04:15:55    Fan failure detected on power supply 1.

(je pensais qu'on avait vérifié ces logs à l'époque, mais apparemment non, en tout cas je viens de retomber dessus en traquant un autre incident…)

Ils sont dans le plan du bas de page évidemment, mais aussi réglables dans les préférences du compte, avec un réglage par défaut d'affichage sur la page d'accueil. On en parle aussi dans Proposer un contenu ou dans l'aide. Et ils ont donc leur partie dédiée

Sur une Ubuntu 24.04 par exemple, juste une petite sélection de quelques logiciels un peu connu :

$ apt rdepends perl|grep -vE "lib.*-perl"|grep Dépend
(...)
  Dépend: chromium
  Dépend: ocsinventory-server (>= 5.14)
(...)
  Dépend: mariadb-server (>= 5.6)
(...)
  Dépend: git
(...)
  Dépend: vmware-manager (>= 5.10.0)
(...)
  Dépend: xen-tools
(...)
  Dépend: sympa (>= 5.8)
(...)
  Dépend: nix-bin
(...)
  Dépend: mimefilter
(...)
  Dépend: debmirror
(...)
  Dépend: spamassassin
(...)

At the same time, because we are part of a European legal entity, F-Droid is obligated to comply with applicable European laws such as the General Data Protection Regulation (GDPR) and assess whether other European legislation like the Digital Services Act (DSA) and the Digital Markets Act (DMA) are applicable in our case.

RGPD: « Il s'applique aux entreprises établies en dehors de l'Union européenne qui traitent les données relatives aux activités des organisations de l'UE. Les sociétés non européennes sont également soumises au règlement dès qu'elles ciblent les résidents de l'UE par le profilage ou proposent des biens et services à des résidents européens. »

DMA : « Le règlement s'applique aux services de plateforme essentiels fournis ou proposés par des contrôleurs d’accès à des entreprises utilisatrices établies dans l’Union ou à des utilisateurs finaux établis ou situés dans l’Union, quel que soit le lieu d’établissement ou de résidence des contrôleurs d’accès et quel que soit le droit par ailleurs applicable à la fourniture des services »

Donc c'est en fait que le service est utilisé par des résidents européens, donc F-Droid est concerné RGPD/DSA/DMA. Et, par ailleurs, F-Droid est basé en Europe, alors il est concerné par toute la législation locale.

Faut aussi penser à NIS2, au Cyber Resilience Act, etc.

Cf https://linuxfr.org/users/cg/liens/the-register-the-year-of-the-european-union-linux-desktop-may-finally-arrive
https://linuxfr.org/users/abriotde/liens/abandon-microsoft
https://linuxfr.org/users/anubis/liens/ministere-du-numerique-danois-sur-la-voie-de-l-independance-a-microsoft

Ne pas faire la montée de version à chaque version donne plus de boulot ensuite (vu qu'il faut gérer une montée de plusieurs versions). Et petit à petit on commence à avoir des soucis de « vieux logiciels » (entre les postes clients à jour et les serveurs en retard par exemple).
Les mises à jour de sécurité sortent d'abord pour la version stable en cours, donc c'est un peu mieux niveau sécurité d'être en stable.
L'idéal pourrait être de tout réinstaller à chaque fois avec la dernière version (ça dépend si on sait automatiser ou bien gérer le transfert des données de l'ancienne à la nouvelle), mais sinon les mises à jour se font très bien.

J'ai fait les montées de version depuis Debian 12 bookworm vers 13 Trixie pour LinuxFr.org sur 3 serveurs, 1 VM et 2 conteneurs LXC par exemple : les releases notes sont très détaillées, les changements annoncés, ça se fait bien. Parce que la quantité de machines est raisonnable. Si je devais gérer des dizaines/centaines/milliers de machines, je ne passerai pas par les mises à jour, j'automatiserais le déploiement d'installations neuves.

Mais ça mériterait d'être précisé dans le site au endroit concerné, je vais laisser l'entrée ouverte pour l'instant du coup.

Il pourrait être utile de figer les IP internes et/ou d'assurer la synchronisation/reconfiguration du frontal web.

Historique (sur des années) : on avait un conteneur LXC daté (que l'on peine à moderniser) avec IP publique sur un hôte daté. On a migré ce conteneur sur un hôte à jour, il s'est retrouvé en IP privée derrière un frontal, puis on a commencé à déplacer des services (SQL, redis, epub, etc.) vers un autre conteneur LXC à jour (avec l'espoir de réduire l'ancien à zéro à terme). Ce qui a donné : un frontal qui doit parler à un conteneur, et un conteneur qui doit parler à un autre conteneur. Avant l'incident, les communications passaient par les adresses IP, attribués dynamiquement par dnsmasq-dhcp.

Situation courante post mesure corrective : dnsmasq-dhcp est configuré pour servir toujours les mêmes IP pour les adresses MAC des conteneurs, et les conteneurs se connaissent par leurs noms. Le frontal continue à utiliser les IP car il est hors de la résolution de noms LXC. Deux petits écueils :

• pour que la résolution fonctionne, il faut que le conteneur ait démarré, donc il faut gérer l'ordre de démarrage des conteneurs (ce qui redonnera 8 min d'interruption le 17 août après un redémarrage pour découvrir cela et corriger).
• étant parti d'un conteneur à IP publique, on se retrouve avec un conteneur nommé par exemple "alpha" associé à une IP publique alpha.linuxfr.org et donc sur l'hôte on a alpha qui a une IP publique et une IP privée. Si ce conteneur était refait de zéro il aurait un nom différent voire aléatoire et ce micro-problème n'existerait pas.

Non parce qu'on a des pénibles indonésiens qui nous spamment chaque jour pour leur casino donc ça nous arrangerait pour LinuxFr.org… (bon spammer étant un tantinet pas très respectueux des règles, pas sûr que ça aide une interdiction officielle)

Corrigé, merci.

Non ce n'est pas possible à l'affichage non plus.

BAud nous dit qu'il est de temps en temps purgé.

C'est faux (depuis 2024 en tout cas), les images de contenus visibles ne sont pas purgées.

1. limiter à des images utilisées uniquement sur linuxfr, par exemples supprimées si pas utilisé dans un commentaire/article/brouillon après N jours

Il y a une procédure de nettoyage (non automatique) qui fait cela. En plus du script check_img de l'audit évoqué dans https://linuxfr.org/news/img-le-cache-d-images-sur-linuxfr-org#toc-laudit-interne

Cf https://linuxfr.org/news/img-le-cache-d-images-sur-linuxfr-org
Ce n'est pas vrai pour les dépêches en markdown images passant par le service img. Les dépêches avant 2011 et en HTML (sauf exceptions déjà converties) ne passent pas par img.

La première question qu'un développeur devrait se poser est de définir quelles sont les questions qu'il devrait se poser. Limite on appellerait ça des exigences ou des spécifications.

(Selon LinuxFr.org, en ce vendredi estival, il devrait commencer par un colloque international pour demander l'avis de toutes les autres personnes qui développent, établissant ainsi une liste exhaustive pour construire cet abri à vélo vert, ensuite on pourrait discuter du meilleur langage, des meilleurs outils et du code parfait, après on pourrait parler des tests)

Je me pose la question depuis longtemps, il y a moyen de redimensionner les images sur LinuxFR ⁈

Non, les images distantes sont juste mises dans un cache local par le service img. Cf https://linuxfr.org/news/img-le-cache-d-images-sur-linuxfr-org

On ne peut pas commenter les journaux de plus de 3 mois.

Il n'y a pas que les changements d'API, aussi ceux d'ABI : C a eu ses problèmes d'ABI notamment avec libc5 et libc6 si je me souviens bien. C++ a eu régulièrement des problèmes d'ABI aussi (gcc2 vs gcc3, les différentes gcc3.x, etc.).

Pouvoir recompiler c'est bien, surtout quand tu es quasi obligé de le faire pour cause d'ABI qui ont changé.

D'ailleurs en fait et précédemment https://linuxfr.org/users/oumph/liens/the-bug-323-community-where-all-x87-floating-point-errors-in-gcc-come-to-die

tousse tousse https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18567 (et coucou Laurent Guerby https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15134 )

Donc je dirais bien sans commentaire.

Corrigé, merci.

Cf fil de commentaires précédent