Linux Mint | Nouvelles mensuelles – février 2021

Merci pour vos dons et pour votre soutien.

Application des mises à jour

Une annonce a été faite la semaine dernière pour expliquer pourquoi les mises à jour de sécurité sont importantes et pour rappeler aux gens de mettre à jour leur ordinateur.

Si vous ne l’avez pas encore lu, veuillez visiter https://blog.linuxmint.com/?p=4030 .

Nous avons commencé à travailler sur des améliorations pour le gestionnaire de mise à jour. Dans la prochaine version, le gestionnaire ne recherchera pas seulement les mises à jour disponibles, il gardera également une trace de mesures particulières et sera en mesure de détecter les cas où les mises à jour sont ignorées. Certaines de ces mesures concernent la date de la dernière application des mises à jour, la dernière mise à niveau des packages sur le système, le nombre de jours d’affichage d’une mise à jour particulière…

Dans certains cas, le gestionnaire de mise à jour pourra vous rappeler d’appliquer les mises à jour. Dans quelques-uns d’entre eux, il pourrait même insister. Nous ne voulons pas que ce soit stupide et que cela vous gêne. C’est là pour vous aider. Si vous gérez les choses à votre façon, il détectera les modèles et les usages intelligents. Il sera également configurable et vous permettra de changer la façon dont il est configuré.

Nous avons des principes clés chez Linux Mint. L’un d’eux est qu’il s’agit de votre ordinateur, pas du nôtre. Nous avons également de nombreux cas d’utilisation à l’esprit et ne voulons pas rendre Linux Mint plus difficile à utiliser pour aucun d’entre eux.

Nous sommes toujours en train d’élaborer des stratégies et de décider quand et comment le gestionnaire de mises à jour devrait se rendre plus visible, il est donc trop tôt pour parler de ces aspects et entrer dans les détails qui vous intéressent probablement le plus ici. Jusqu’à présent, nous avons travaillé à rendre le gestionnaire plus intelligent et à lui donner plus d’informations et plus de mesures à examiner.

Corrections de bogues

Les mises à jour des packages ont été publiées hier pour les projets suivants : xapp, warpinator, nemo, cinnamon-menus, nemo-dropbox, nemo-media-columns, nemo-python. Ils représentent un nombre important de changements et résolvent une variété de problèmes.

Sur les ordinateurs rapides, un composant xapp peut retarder jusqu’à une seconde le temps de connexion. Cela était en place pour garantir la compatibilité de la barre d’état système pour les indicateurs et les applications QT et il tenait la session pour s’assurer que la barre d’état système était en place avant toute application démarrée automatiquement. Cette fonctionnalité a été repensée et le délai n’existe plus.

De nombreux problèmes d’utilisabilité et de niche liés aux favoris ont été résolus.

Un problème a été trouvé dans la façon dont Nemo a géré les calculs de style. Le redimensionnement des fenêtres du navigateur de fichiers peut entraîner une accumulation de recalculs et éventuellement créer une latence de mise au point après un certain temps. Cela a été corrigé.

Des fuites de mémoire ont également été trouvées et corrigées dans Nemo et certaines de ses extensions.

Les opérations sur les fichiers et la gestion des vignettes ont reçu des améliorations de performances et de stabilité.

Sur le bureau lui-même, des bogues d’utilisabilité affectant les polices en gras et l’ordre de tri des icônes ont été corrigés.

Plymouth + LUKS Bug et versions reproductibles

Lorsque la possibilité de mise à niveau de Linux Mint 20 vers Linux Mint 20.1 a été permise, nous avons reçu des commentaires et des rapports de bogues liés à un problème plymouth sur les ordinateurs avec des lecteurs chiffrés LUKS.

Nous n’avons pas pu identifier la cause du problème. Parce que le problème n’a affecté que certains utilisateurs, nous avons d’abord pensé qu’il était lié au matériel et qu’il avait quelque chose à voir avec les pilotes NVIDIA.

Avant d’expliquer ce qui s’est passé et ses conséquences, si vous attendiez ce correctif, je tiens à m’excuser pour le temps qu’il a fallu et à vous remercier de votre patience. À partir d’aujourd’hui, ce bogue est corrigé. Nous avons identifié sa cause vendredi et nous avons envoyé une mise à jour du paquet Plymouth vers nos dépôts aujourd’hui qui corrige le problème.

L’histoire ne s’arrête cependant pas là. Ce bogue nous a fait prendre conscience d’un problème très important qui affecte Ubuntu (et Debian aussi, mais dans une bien moindre mesure), le problème des constructions non reproductibles.

C’est assez technique. Lorsque nous sommes passés de Linux Mint 19.3 à Linux Mint 20, nous sommes passés d’une base de paquets Ubuntu 18.04 à une base de paquets Ubuntu 20.04. Une différence importante entre ces deux bases de paquet est le fait qu’Ubuntu 20.04 est un système fusionné (c’est-à-dire un système où certains chemins tels que / bin et / usr / bin sont fusionnés via des liens symboliques et sont effectivement les mêmes, ceci est décrit ici: https : //wiki.debian.org/UsrMerge ).

Sur un système fusionné, si un package place un binaire dans / bin et qu’un autre package l’appelle avec le mauvais chemin (/ usr / bin par exemple), cela n’a pas d’importance, cela fonctionne quand même. C’est une amélioration pour les utilisateurs, mais cela masque également les problèmes potentiels du point de vue du responsable. Si vous empaquetez quelque chose avec le mauvais chemin, votre paquet continue de fonctionner sur les systèmes fusionnés, mais pas sur les systèmes non fusionnés.  

À partir de la version 20.1, Linux Mint a également adopté usrmerge et toutes les nouvelles installations sont fusionnées. Dans le cadre de la mise à niveau de Linux Mint 20, nous avons recommandé aux gens de fusionner leur système, mais tout le monde ne l’a pas fait. Nous étions conscients de ces problèmes potentiels à l’époque et nous l’avons expliqué dans les instructions de mise à niveau. Cela a été fait de la même manière par Debian et par Ubuntu lors de leur fusion. Toutes les distributions s’engagent à prendre en charge les deux systèmes.

Debian est cependant été plus loin et a compris l’impact que cela pouvait avoir sur les processus de construction. Si un package analyse son environnement de génération pour évaluer le chemin d’un binaire particulier et injecte ce chemin dans les packages résultants, des problèmes peuvent survenir si l’environnement de génération est différent de celui de l’utilisateur.

Prenez par exemple plymouth, lorsque vous le compilez à partir des sources, il analyse l’environnement de construction pour trouver le chemin d’un binaire systemd appelé systemd-tty-ask-password-agent. Sur les systèmes Debian, le paquet systemd fournit ce binaire et le place dans / bin. La version plymouth utilise des autotools et une routine appelée AC_PATH_PROG pour trouver le chemin de systemd-tty-ask-password-agent, puis injecte ce chemin dans le service systemd qu’il fournit pour l’appeler.

Sur un ordinateur non fusionné, systemd-tty-ask-password-agent est dans / bin (où le paquet systemd le place). Sur un ordinateur fusionné, il est à la fois dans / bin et dans / usr / bin (puisque ces deux répertoires sont les mêmes ici).

Si vous compilez le paquet source plymouth sur un ordinateur non fusionné, il trouve systemd-tty-ask-password-agent dans / bin et injecte « / bin / systemd-tty-ask-password-agent » dans son fichier de service. Ce chemin fonctionne à la fois sur les systèmes fusionnés (où le correctif n’a pas d’importance) et sur les systèmes non fusionnés (puisque le chemin est correct).

Si vous compilez le paquet source plymouth sur un ordinateur fusionné, il trouve systemd-tty-ask-password-agent dans / usr / bin et injecte « / usr / bin / systemd-tty-ask-password-agent » dans son fichier de service. Ce chemin est incorrect et ne fonctionnera donc que sur les systèmes fusionnés.

Debian a compris l’importance d’obtenir le même résultat à partir de builds dans différents environnements. En d’autres termes, que l’environnement de construction soit fusionné ou non, non seulement les packages résultants doivent fonctionner sur tous les systèmes, mais ils doivent également être identiques en tous points. Debian exécute des contrôles d’intégration continus pour s’assurer que toutes ses constructions sont reproductibles et corrige les paquets là où ce n’est pas le cas.

Le code source de Plymouth a en effet été patché dans Debian pour éviter ce problème, mais pas dans Ubuntu. Pire encore, et c’est vraiment important dans notre cas, depuis 20.04 (et donc pour nous depuis Mint 20, pas 20.1), les images du docker Ubuntu et les systèmes utilisateurs sont fusionnés, mais l’environnement de construction du Launchpad ne l’est pas. En d’autres termes, certains paquets source disponibles dans la version 20.04 produisent des paquets qui sont différents de ce qui se trouve dans les référentiels lorsqu’ils sont reconstruits. Parce que l’infrastructure de construction Ubuntu pour 20.04 n’a pas encore été fusionnée, nous n’avons pas à nous soucier des paquets binaires construits par Ubuntu (que les versions de paquet source ne soient pas reproductibles ou non, si elles sont construites sur des environnements non fusionnés, elles va travailler partout).

Parce que nous utilisons principalement docker pour construire nos paquets et que nos images (depuis 20.04) sont fusionnées, nous devons nous en préoccuper autant que Debian l’a fait et non seulement résoudre ce problème particulier, mais nous assurer que nous détectons toutes les versions non reproductibles. Aller de l’avant et corriger tout ce qui introduit de la variabilité et qui n’a pas déjà été corrigé en amont. Nous développerons des outils internes dès que possible pour résoudre ce problème. Nous examinerons également nos propres projets de distributions croisées (Cinnamon, xapp pour n’en nommer que quelques-uns) et nous assurerons qu’ils ne scannent pas les chemins de cette façon ou n’introduisent pas ce genre de problèmes dans leur construction.

Améliorations de Cinnamon

Bien que la solution à une fuite de mémoire soit un correctif, certaines fuites ne sont pas détectées pendant des années. La plupart du temps, c’est parce qu’ils sont spécifiques au matériel ou au pilote, parfois, c’est simplement parce que le rapport de bogue ne signale pas quelque chose de spécifique qui nous manque et que nous ne pouvons pas reproduire le problème.

Cinnamon lui-même s’appuie sur un grand nombre de vos pilotes GPU. Il peut utiliser entre 80 Mo et 1 Go de RAM en fonction de votre système et de ce que vous lui demandez de faire. Il est particulièrement petit sur les pilotes Intel et open-source et particulièrement gros sur les pilotes NVIDIA propriétaires 64 bits. Il commence également petit et utilise plus de mémoire lorsque vous activez davantage de ses fonctionnalités. Il se développe généralement avec le temps et jusqu’à un certain point. Ce point dépend du nombre d’applets que vous utilisez, du fait que vous utilisiez toutes ses fonctionnalités et du système sur lequel vous vous trouvez. Passé ce point, si Cinnamon continue de croître indéfiniment, vous êtes à la recherche d’une fuite de mémoire.

Nous savons qu’il y a encore quelques fuites parce que nous entendons parler de personnes qui reviennent à leur ordinateur après des jours d’inactivité pour trouver leur processus Cinnamon en utilisant 2 Go, 4 Go, 6 Go de RAM. Nous ne savons pas encore la cause de ces fuites, mais nous aurons une solution de contournement dans Cinnamon 5.0.

En utilisant les paramètres systèmes, vous pourrez définir une quantité maximale de RAM que Cinnamon peut utiliser.

Si cette quantité maximale est atteinte, Cinnamon redémarrera de lui-même. Vous ne perdrez pas votre session ou vos fenêtres, il ne répondra pas pendant environ une seconde pendant qu’il redémarre en interne. Il conservera un journal de ces événements afin que vous puissiez voir si cela se produit souvent et nous aider à résoudre le problème.

Une autre chose que nous améliorons est la gestion des épices. Dans les versions précédentes de Cinnamon, il y avait des différences entre l’onglet installé et l’onglet de téléchargement pour les applets, desklets et extensions. 

Nous avons modifié la façon dont les choses fonctionnent pour s’assurer que tout est correctement traduit et que toutes les épices ont le même nom, icône et description, qu’elles soient installées ou non.

Nous affichons également plus d’informations telles que le nom de l’auteur et l’ID unique de l’épice et nous travaillons actuellement sur la possibilité d’installer graphiquement des épices ZIP tierces.

Nous avons également renforcé la validation et la traduction des épices et mis en place une intégration continue.

Source : https://blog.linuxmint.com/?p=4037