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
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
*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.
 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
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