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


En savoir plus sur Blabla Linux 🇧đŸ‡Șâ™»ïžđŸ’»đŸ§đŸ‡«đŸ‡·

Abonnez-vous pour recevoir les derniers articles par e-mail.

2 réflexions sur “Linux Mint | Nouvelles mensuelles – fĂ©vrier 2021

  1. bonjour, depuis que je suis passĂ© Ă  linux mint 20.2 via les mises Ă  jour, mon nom d’utilisateur et de root n’apparait plus ; je suis coincĂ© pour tous les demandes qui exigent ce nom d’utilisateur (+ password) et notamment pour crĂ©Ă©r une clĂ© de dĂ©marrage. J’ai fouillĂ© partout sur le net et je n’ai rien trouvĂ© pour m’aider.
    merci pour votre aide. Roger

    1. Bonjour Roger. Je ne comprends pas bien votre problĂšme. Nom utilisateur disparu du oĂč ? Vous savez vous connectez Ă  votre session ? Ensuite « root » n’est pas utilisĂ©, sur Mint on Ă©lĂšve les privilĂšges avec « sudo ». Donc c’est l’utilisateur qui Ă  les privilĂšges. Ensuite je ne comprends pas non plus ce que vous appelez clĂ© de dĂ©marrage ?

Laisser un commentaire