openSUSE Users (Français) October 2019

users-fr@lists.opensuse.org

2 participants
4 discussions

[opensuse-fr] Traduction: information sur le vote pour le changement de nom du projet

by Sébastien 'sogal' Poher

Bonjour à tous, Comme vous le savez sûrement un vote pour évaluer la pertinence d'un changement de nom du projet openSUSE est en cours. À la demande d'une partie de la communauté, le Conseil et le comité des élections ont rédigé un résumé [0] du contexte et implications du vote. Il a été traduit en français [1], en voici le contenu: ---------------------- # Vote sur le changement de nom du projet openSUSE ## Contexte Une discussion sur le changement de nom de notre projet a eu lieu sur la liste de diffusion du projet suite à une autre discussion concernant la transformation du projet en fondation. Cette dernière proposition a été annoncée par le Conseil du projet lors de la conférence annuelle. Par la suite, il a été proposé que, si le nom du projet devait être modifié, la transformation du projet en fondation était une bonne occasion de le faire. Les avantages et les conséquences du changement de nom du projet ont été discutés sur la liste de diffusion du projet pendant plusieurs semaines. Stasiek Michalski (LCP) a posé la question et Richard Brown a fourni des perspectives juridiques après avoir discuté avec des collègues de l'équipe juridique SUSE. Après avoir consulté un avocat spécialisé, le Conseil a souligné que les deux entités juridiques indépendantes (openSUSE et SUSE) pourraient conserver leurs marques respectives de façon concurrente, de sorte que l'existence des deux marques déposées ne constitue pas un obstacle. Les discussions sur le changement ou la conservation du nom du projet peuvent être résumées comme suit: ### Pourquoi devrions-nous conserver le nom du projet actuel? * Nous perdrions la réputation de la marque openSUSE, durement acquise au fil des ans. * De nombreux membres et autres contributeurs sont fortement attachés au nom actuel. * Changer le nom peut donner l’impression que la relation entre SUSE et openSUSE est tendue. * Il faudra beaucoup de travail pour renommer les domaines, les projets OBS et leurs métadonnées, l’espace de noms GitHub, les marques de paquets, etc. * Le changement de marque nécessite une campagne de communication active (et donc de l'argent) au fil des ans pour ancrer le nouveau nom du projet dans les esprits. * SUSE peut transférer ou céder sous licence la marque déposée à la (future) fondation openSUSE. * La relation avec SUSE fait partie de notre stratégie marketing, par exemple lorsque nous mettons en avant la base de code partagée entre Leap et SLE. * Changer le nom du projet rendra obsolètes les goodies openSUSE actuels (T-shirts, mugs, autocollants, etc.). ### Pourquoi devrions-nous changer le nom du projet? * openSUSE est souvent mal écrit et/ou mal prononcé (par exemple, OpenSUSE, OpenSuSE, etc.). Regardez comment dites-vous SUSE? * La Free Software Foundation (FSF) ne recommande pas l'usage du terme "ouvert", très flou. * La distinction entre openSUSE et SUSE peut être source de confusion pour les personnes novices dans l'une ou l'autre de ces marques. De nombreuses personnes raccourcissent ainsi openSUSE en SUSE. * Si la communauté pense que le projet tirera bénéficie d’un nouveau nom, c'est maintenant qu'il convient de le modifier, c'est-à-dire avant l'enregistrement d'une nouvelle structure juridique (telle qu'une fondation). *Les arguments ci-dessus ne reflètent en aucun cas les positions du conseil ou du comité des élections.* ## Vote La communauté reste divisée sur le sujet et en de telles circonstances, il n’est pas simple d’envisager un consensus en se basant uniquement sur les discussions des listes de diffusion. Le Conseil a donc demandé au comité des élections de mettre en place un vote afin d'obtenir la décision de la communauté d'une manière plus claire et mesurable. Le comité des élections a annoncé que le vote aurait lieu du 10 octobre au 7 novembre 2019. Le comité des élections peut être contacté à l’adresse [mailto: election-officials(a)opensuse.org election-officials(a)opensuse.org] pour toute question relative à ce vote. Processus de vote Le vote électronique a lieu sur elections.opensuse.org, la même plate-forme utilisée lors des élections au Conseil. Les membres ont reçu leur lien de vote électronique et leurs identifiants d'accès à leur alias de courrier électronique @opensuse.org. Ils peuvent ensuite se connecter et voter. Ils peuvent également modifier leur vote à tout moment avant 23h59 UTC le 7 novembre 2019, seul le dernier vote étant enregistré. ## Question mise au vote Changeons-nous le nom du projet? [] Oui [] Non La question reste simple afin d’éviter toute ambiguïté ou risque de parti pris de la part du Conseil ou du comité des élections. Les questions plus détaillées auraient été (pour des raisons techniques, cela n'a pas été possible car le vote était déjà en cours): [] Je suis favorable à la modification du nom de notre projet "openSUSE" et au remplacement des utilisations du nom "openSUSE" par un nouveau nom. Je souhaite que le Conseil du projet openSUSE et SUSE travaillent ensemble pour atteindre cet objectif. (Les prochaines étapes comprendront la détermination de propositions concrètes et un vote sur le choix effectif.) (Ceci correspond au vote Oui.) [] Je suis favorable au maintien du nom "openSUSE" pour notre projet et aimerait voir le Conseil et SUSE travailler ensemble pour faire tout ce qui est nécessaire (en termes de marques et d’autres accords) pour permettre cela. (Ceci correspond au vote Non.) Résultat Le résultat du vote sera annoncé le 8 novembre 2019. Les membres recevront le résultat par courrier électronique. Le résultat sera également publié sur news.opensuse.org et annoncé sur la liste de diffusion du projet. [0] https://en.opensuse.org/openSUSE:Project_name_change_vote [1] https://fr.opensuse.org/openSUSE:Vote_pour_le_changement_de_nom_du_projet -- 'When there is no more room at school, the dumb will walk the Earth.' Sébastien 'sogal' Poher

2 years

[opensuse-fr] KDE et openSUSE: Plasma 5.17, Qt 5.14 plus encore

by Sébastien 'sogal' Poher

Voici les dernières nouvelles du développement d'openSUSE Tumbleweed ------------------------ Plasma 5.17 Beta La version bêta de Plasma 5.17 a été publiée avec de nombreuses nouvelles fonctionnalités et améliorations telles que la mise à l’échelle fractionnelle par écran sur Wayland, une nouvelle interface utilisateur pour la configuration des autorisations des périphériques Thunderbolt et des statistiques réseau dans KSysGuard. Ce dernier nécessite plus de privilèges que d’habitude pour une application utilisateur. C’est pourquoi l’équipe de sécurité SUSE est en train de vérifier ces autorisations. openQA a déjà trouvé quelques bogues, comme GIMP plus “en couleurs” que d’habitude et certaines applications telles que Kirigami et Qt Widgets qui casse certains raccourcis clavier. Les deux ont été corrigés dans l’intervalle et seront corrigés dans la version finale de 5.17. Si vous n’avez pas encore testé Plasma 5.17 Beta, il reste encore un peu de temps! Si vous rencontrez un problème dans le logiciel, veuillez vous rendre sur KDE bug tracker. Si au lieu de cela vous trouvez un problème spécifique à openSUSE, rendez vous sur l’openSUSE bugzilla. Pour obtenir Plasma 5.17 sur votre installation Leap ou Tumbleweed, vous pouvez lire https://fr.opensuse.org/SDB:KDE_repositories. Si vous rencontrez des problèmes graves, l’instantané automatique du système de fichiers racine pris à l’aide de [btrfs] (https://en.wikipedia.org/wiki/Btrfs) vous aide à revenir à l’état de fonctionnement en démarrant dans un instantané plus ancien et en faisant une restauration. Argon, un support live installable comprenant Leap 15.1 avec la version bêta et ne nécessitant aucun ajout de dépôt manuel, est également disponible. openSUSE Leap 15.2 Comme ce fut le cas pour Leap 42.2, 15.2 inclura également des mises à jour majeures de nombreux composants. A côté d’une nouvelle version du noyau Linux, il est prévu de la livrer avec Qt 5.12 LTS, Plasma 5.18 (bien sûr également LTS) et les dernières versions de KDE Frameworks et Applications, que nous pourrons faire entrer suffisamment tôt pour que les tests appropriés garantissent la meilleure expérience utilisateur possible! Cela signifie que la session “Full Wayland” qui a atterri dans Tumbleweed il y a quelques semaines sera également disponible dans Leap 15.2 de même que la prise en charge de la mise à l’échelle fractionnelle par écran. Comme les versions cibles d’Applications, Frameworks et Plasma ne sont pas encore connues, nous intégrons actuellement Qt 5.12 LTS aux derniers packages de Factory. Qt 5.14 Les utilisateurs de Tumbleweed et de Leap sont habitués à bénéficier des versions les plus récentes des logiciels KDE incluant les fonctionnalités et corrections de bogues disponibles, ce qui n’est possible qu’en suivant le développement de Qt et en agissant de manière proactive. Ainsi, bien que la branche 5.1 de Qt soit encore jeune, nous sommes déjà en train de l’intégrer dans nos versions. Lors de la construction initiale de la version 5.14 Alpha, certains bogues (QTBUG-78867, QTBUG-78881, QTBUG-78911, QTBUG-78948) avaient déjà été identifiés et corrigés pour la plupart, de sorte que le projet KDE:Qt:5.14 est construit et utilisable dès maintenant. Pour développer avec Qt 5.14 et tester vos applications, vous n’avez plus qu’à ajouter le dépôt. Jusqu’ici, nous en sommes toujours à la phase d’intégration et nous préparons tout ce qui doit l’être, mais nous soumettrons bientôt Qt 5.14 en zone de transit de Factory afin de voir comment il s’y intègre. L’une des caractéristiques les plus visibles pour l’utilisateur est que la mise en œuvre de la mise à l’échelle (pour les écrans HiDPI) a été principalement réécrite. Parmi les autres changements notables, citons l’ajout de divers systèmes d’accélération de Qt Quick utilisant une nouvelle couche d’abstraction (opt-in), qui peut désormais tirer parti de Vulkan ainsi que l’introduction d’un nouveau module “qtquicktimeline”, qui permet de faciliter intégration d’animations basées sur la chronologie dans Qt Quick. source: https://news.opensuse.org/2019/10/10/kde-and-opensuse-plasma-5-17-qt-5-14-a… -- 'When there is no more room at school, the dumb will walk the Earth.' Sébastien 'sogal' Poher

2 years

[opensuse-fr] Lumière sur le développement de YaST - Sprint86

by Sébastien 'sogal' Poher

*Voici une traduction des annonces de l'équipe de développement de YaST* Maintenant que vous avez eu l'occasion de consulter [notre message sur les options de chiffrement avancées](https://lizards.opensuse.org/2019/10/09/advanced-encryption-yast/) (en particulier si vous êtes un utilisateur de s390), il est temps de vérifier ce qui s’est passé lors du dernier sprint de développement YaST, qui s’est achevé lundi dernier. Comme d'habitude, nous avons travaillé sur un large éventail de sujets, notamment: - Amélioration de la prise en charge des systèmes de fichiers multi-périphériques dans le partitionneur expert. - Résolution des problèmes de réseau, de démarrage sécurisé et de kdump dans AutoYaST. - Plus d'attente de `chrony` lors du démarrage initial lorsque cela n'a pas de sens. - Préparation de la prise en charge de la scission des fichiers de configuration entre `/usr/etc` et` /etc`. - Utilisation de `/etc/sysctl.d` pour écrire les paramètres liés à YaST au lieu du fichier principal `/etc/sysctl.conf`. ### Expert Partitioner et systèmes de fichiers multi-périphériques Jusqu'à présent, le partitionnement en mode expert partait du principe que Btrfs était le seul système de fichiers construit sur plusieurs périphériques. Mais ce n'est pas tout à fait vrai, car certains systèmes de fichiers peuvent utiliser un journal externe pour améliorer les performances. Par exemple, *Ext3/4* et *XFS* peuvent être configurés pour utiliser des périphériques distincts pour les données et la journalisation. Nous avons reçu un [rapport de bogue](https://bugzilla.suse.com/show_bug.cgi?id=1145841) causé par ce malentendu sur les systèmes de fichiers multi-périphériques. Le partitionneur expert désignait comme "faisant partie de Btrfs" un périphérique utilisé comme journal externe d'un système de fichiers *Ext4*. Nous avons donc amélioré cette fonctionnalité lors du dernier sprint et les périphériques de journal externes sont maintenant correctement indiqués dans la colonne *Type* du Partitionneur expert, comme illustré dans la capture d'écran ci-dessous. ![Type de journal externe](http://lizards.opensuse.org/wp-content/uploads/2019/10/yast2-stora… De plus, les informations sur le système de fichiers indiquent maintenant quel périphérique est utilisé pour le journal externe. ![Détails du périphérique de journal externe](http://lizards.opensuse.org/wp-content/uploads/2019/10/yast2-stora… Enfin, nous avons également limité l’utilisation des périphériques appartenant à un système Btrfs multi-périphériques. À présent, vous recevrez un message d'erreur si vous essayez de modifier l'un de ces périphériques. À l'avenir, nous étendrons cette fonctionnalité pour permettre de modifier les systèmes de fichiers utilisant un journal externe via le Partitionneur expert. ### AutoYaST a fait l'objet de notre attention Au cours de ce sprint, nous avons accordé à AutoYaST une attention particulière dans différents domaines: réseaux, chargeur de démarrage et kdump. À propos de la zone réseau, nous avons terminé la prise en charge de s390 dans la nouvelle couche réseau, en corrigeant certaines anciennes limitations en matière d’activation de périphériques et de gestion d’UDev. En dehors de cela, nous avons corrigé plusieurs bugs et amélioré beaucoup la documentation, car nous la trouvions plutôt incomplète. Un autre changement important a été l'ajout de la possibilité de désactiver le démarrage sécurisé pour UEFI via AutoYaST. Bien sûr, nous avons également mis à jour la documentation et, au cours du processus, nous avons ajouté des éléments manquants et supprimé d'autres éléments inutiles. Enfin, nous avons corrigé un problème délicat lorsque nous essayons de faire fonctionner kdump sur un système minimal. Après débogage, nous avons découvert qu’AutoYaST ajoutait trop tard `kdump` à la liste des paquets à installer. Ce problème a été résolu et il devrait maintenant fonctionner comme un charme. Comme vous l'avez peut-être vu, à part l'écriture de code, nous essayons de contribuer à la documentation afin que nos utilisateurs disposent d'une bonne source d'informations. Si vous êtes curieux, en plus des documents pour les versions [SUSE](https://suse.com/documentation) et [openSUSE](https://doc.opensuse.org/) publiées, vous pouvez consulter les [dernières versions](https://susedoc.github.io/) (y compris le [manuel AutoYaST](https://susedoc.github.io/doc-sle/master/SLES-autoyast/html)). Félicitations à notre équipe de documentation pour cet extraordinaire travail ! ### Éviter le temps mort `chrony-wait` Récemment, certains utilisateurs d’openSUSE ont signalé un problème très gênant dans Tumbleweed. Lorsque la synchronisation de l'heure est activée via YaST, le système peut rester bloqué pendant le processus de démarrage si aucune connexion réseau n'est disponible. Le problème est que, mis à part le service `chrony`, YaST activait également le service` chrony-wait`. Ce service est utilisé pour garantir que l'heure est correctement définie avant de continuer avec d'autres services pouvant être affectés par un décalage temporel. Mais sans connexion réseau, `chrony-wait` attendra environ 10 minutes. Inacceptable. La discussion sur le correctif de ce bogue est toujours ouverte, mais pour le moment, nous avons appliqué une solution de contournement dans YaST afin d'activer `chrony-wait` uniquement pour les produits nécessitant une heure précise, comme openSUSE Kubic. Dans le reste des cas, les systèmes démarreront plus rapidement, même sans réseau, bien que certains services puissent être affectés par un décalage temporel. ### Fractionnement des fichiers de configuration entre `/etc` et `/usr/etc` En tant qu'utilisateurs Linux, nous sommes tous habitués à vérifier les paramètres du système dans `/etc`, qui contient un mélange de valeurs de configuration propres au fournisseur et à l'hôte. Cette approche a plutôt bien fonctionné dans le passé, non sans quelques ratés, mais lorsque des choses comme [les mises à jour transactionnelles](https://en.opensuse.org/openSUSE:Packaging_for_transacti… entrent en jeu, la situation devient compliquée. Afin de résoudre ces problèmes, il est prévu de scinder les fichiers de configuration entre `/etc` et `/usr/etc`. Le premier contiendrait les paramètres du fournisseur, tandis que le second définirait des valeurs spécifiques à l'hôte. Bien sûr, une telle démarche a de nombreuses implications. Au cours de ce sprint, nous avons donc essayé d'identifier les problèmes potentiels pour YaST et de proposer des solutions pour les résoudre à l'avenir. Si vous êtes intéressé par les détails techniques, vous pouvez lire [nos conclusions](https://github.com/yast/yast-yast2/blob/2975c70ab17f1bc790c0ca…. ### Écrire les modifications de Sysctl dans `/etc/sysctl.d` Pour pouvoir gérer la séparation de `/etc` et `/usr/etc`, YaST doit arrêter d’écrire dans des fichiers tels que `/etc/sysctl.conf` et utiliser un fichier spécifique dans les répertoires `.d` (comme `/etc/sysctl.d`). Ainsi, dans le cadre de la recherche susmentionnée, nous avons adapté plusieurs modules (`yast2-network`,` yast2-tune`, `yast2-security` et` yast2-vpn`) afin qu'ils se comportent de cette manière concernant `/etc/sysctl.conf`. À partir de maintenant, les paramètres spécifiques à YaST seront écrits dans `/etc/sysctl.d/30-yast.conf` au lieu de `/etc/sysctl.conf`. De plus, si YaST trouve l'un de ces paramètres dans le fichier `.conf` général, il les déplacera au nouvel emplacement. ### Et après? Sprint 87 est déjà en cours. Outre la correction de certains bugs introduits lors de la refactorisation du réseau, nous prévoyons de travailler sur d'autres tâches liées au stockage, telles que le support du redimensionnement pour LUKS2 ou certains problèmes liés a snapper. Nous vous donnerons plus de détails dans notre prochain rapport de sprint. Restez à l'écoute! -- 'When there is no more room at school, the dumb will walk the Earth.' Sébastien 'sogal' Poher -- To unsubscribe, e-mail: opensuse-fr+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-fr+owner(a)opensuse.org

2 years

[opensuse-fr] Annonce de fin de vie pour openSUSE Leap 15.0

by Sébastien 'sogal' Poher

Dans un message publié sur les listes de diffusion du projet openSUSE, Marcus Meissner, de l'équipe de maintenance SUSE et openSUSE, a annoncé la fin de support d'openSUSE Leap 15.0. En voici une traduction: Le 30 novembre 2019, openSUSE Leap 15.0 atteindra la fin de sa période de support après une durée de vie d'un an et demi (cette version est parue en mai 2018). En conséquence, openSUSE Leap 15.0 ne bénéficiera plus de mises à jour de maintenance ou de sécurité après cette date. Il est donc fortement recommandé aux utilisateurs de procéder à la mise à jour vers la version actuelle, à savoir openSUSE Leap 15.1. La prochaine publication de la distribution, openSUSE Leap 15.2, est prévue pour mai 2020. -- 'When there is no more room at school, the dumb will walk the Earth.' Sébastien 'sogal' Poher -- To unsubscribe, e-mail: opensuse-fr+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-fr+owner(a)opensuse.org

2 years

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openSUSE Users (Français) October 2019