Reprise du message précédent :

 
C'est français:
 
https://fr.wikipedia.org/wiki/Mitig [...] aut%C3%A9.

 
C'est français:
 
https://fr.wikipedia.org/wiki/Mitig [...] aut%C3%A9.

 
Pareil, tu prends au hasard quelqu'un dans la rue, il y aura une forte probabilité qu'il ne connaisse pas ce mot "mitigation", il utilisera plutôt spontanément le terme "atténuation, réduction, adoucissement" que "mitigation".
Avec la logique il va essayer de deviner le sens du mot (en se basant sur le verbe "mitiger" ), sans être vraiment sûr de son coup.
 
Il y a un topic qui répertorie les mots français très peu utilisés :
https://forum.hardware.fr/hfr/Discu [...] 7603_1.htm
 
Sur les 60000 mots du dictionnaire français il n'y en a que 600 qui sont réellement utilisés dans la vie de tous les jours  .

Pourtant je parie qu'ils connaissent tous des mots comme solutionner.

D'ailleurs je crois qu'on parle de mots usités et non utilisés mais je ne suis plus francophone depuis si longtemps, je peux me tromper.

C'est aussi une histoire de génération, avec les jeunes qui ont tendance à inventer des expressions, des mots inspirés de l'anglais,

par exemple quelqu'un d'un peu vieux (quarantaine) sera un peu choqué par l'emploi à toutes les sauces du verbe "impacter", il y 20~30 ans c'était très peu utilisé, on disait plutôt "j'ai été touché, affecté par tel évènement",
maintenant (dans les médias, les conversations de bistrot) le terme "impacter" a tendance à être majoritaire, à force de l'entendre partout les gens l'ont adopté, un coté "impact de balle" pour accentuer les conséquences d'un truc.

Idem pour solutionner plutôt que résoudre, ça pique aux oreilles pour certains, pas pour d'autres .

Je n'ai jamais entendu ce mot impacter, est-ce nouveau?

Je dirai qu'il s'est généralisé depuis le début des années 2000, avec les politiciens, les économistes, les journalistes qui l'emploient souvent pour parler de la crise économique, des grèves :
 
https://www.lefigaro.fr/langue-fran [...] ancais.php

Je vois, merci!

Et très couramment en informatique pour parler de l’impact de telle ou telle chose sur les performances du système, par exemple.
Prochain mot : « optimiser ». Lui aussi, j’ai appris il y a seulement quelques années que c’était un pur barbarisme employé à la place d’« améliorer » (enfin, plus qu’un synonyme, ça désigne plutôt l’idée générale derrière).

Une page intéressante sur tous mots a éviter:
 
http://www.academie-francaise.fr/l [...] normatives
 
(promis j’arrête la! )

pour les explications.

Juste pour info : apparemment, mes problèmes de crashs intempestifs de VLC ont disparu mercredi, aussi soudainement qu’ils sont apparus lundi. Je n’ose penser que la mise à jour de systemd (la seule qu’il y a eu ce matin-là pour moi, avec git), effectuée justement mercredi matin, ait pu avoir un rôle là-dedans, mais bon, je vais pas me plaindre que tout refonctionne bien.

Je découvre ArcoLinux qui me semble une (peut-être meilleure) alternative à Anarchy.

J'aime surtout le choix de DE/WM qu'ils proposent et qui fonctionnent out-of-the-box :
- AWESOME
- BSPWM
- BUDGIE
- CINNAMON
- DEEPIN
- ENLIGHTENMENT
- GNOME
- HERBSTLUFTWM
- i3WM
- JWM
- LXQT
- MATE
- OPENBOX
- PLASMA
- QTILE
- SPECTRWM
- UKUI
- XFCE
- XMONAD

À voir si ça n'installe pas trop de merdouilles en même temps.

J'ai réinstallé une arch toute neuve sur un vieux PC via Anarchy et je dois dire que c'est du bon taff. C'est propre, facile et rapide (dépend de la connexion, faut pas déconner. )
Bon, je n'ai pas testé sur un PC avec plusieurs OS et disques donc je ne sais pas si cela fout le bordel sur ce point.  
 
En tout cas, le projet évolue bien.
 
Il y a néanmoins des bugs à la con comme le clavier qui est resté en anglais durant l'installation...Je n'avais pas fait attention quand j'ai tapé le mot de passe.   Les aléas du tout graphique à la Dwarf fortress.  

Attends : si, à l’installation, tu configures bien le clavier français, ça vaut ensuite pour les consoles TTY et l’écran de connexion graphique. Mais une fois dans l’environnement de bureau, tu es de nouveau en clavier US de base. Il faut donc configurer le clavier pour le DE, car c’est un réglage totalement distinct.

J'ai peut-être fait une erreur.
En tout cas, mon mot de passe est en querty et tout le reste est bien azerty. C'est curieux mais bon. Comme je dis, j'ai du faire une erreur à un moment.

Nouvelle petite « surprise » pour pimenter la vie des utilisateurs d’Arch (ça faisait longtemps… ) : si vous avez fait la mise à jour de pam et pambase, évitez de verrouiller votre session si vous voulez pas vous faire « enfermer dehors ».
 
J’explique : tout à l’heure, j’ai verrouillé ma session (XFCE, avec XScreenSaver). Sauf qu’au moment de la déverrouiller, je n’ai pas eu la boîte de dialogue habituelle qui s’affiche quand je tape mon mot de passe. En fait, j’ai eu un message me disant que l’authentification avait échoué au moins 3 fois, et que ma session était donc bloquée pour 10 minutes. Sauf que, 10 minutes plus tard, même topo…
J’ai voulu me connecter depuis une console TTY, et… Pareil : compte verrouillé, impossible de m’y connecter. Je me suis littéralement fait enfermer hors de mon propre PC !
Il a fallu que je me connecte en root (pour la première fois depuis l’installation, en juillet 2016 !) et demande à redémarrer pour pouvoir à nouveau entrer dans ma session ! Heureusement que j’avais pas de fichier ouvert et non enregistré (mais ceux qui en avaient et y ont aussi eu droit, ils seront contents !).
 
Le bug a été signalé par quelqu’un qui utilise Gnome, donc j’ai mis un commentaire pour dire que ça dépendait pas du DE, et que c’était en fait lié à l’apparition d’un nouveau fichier dans le paquet de pam : /etc/security/faillock.conf. Sauf que j’y vois pas comment virer cette limite des 3 tentatives échouées (je n’ose pas mettre 0…), sachant que ça bloquait dès la première.
 
En attendant, j’ai enlevé l’option de verrouillage de la session du menu d’actions de XFCE, pour éviter que ça recommence…
 
EDIT : ah, ben, décidément… On signale aussi, sur le forum d’Arch, des bugs avec les applications en Qt5. J’ai d’ailleurs remarqué à l’instant le phénomène avec VLC et la boîte de dialogue des paramètres de Qt5 (qt5ct) : si je les lance depuis un raccourci ou le menu des applications de XFCE, VLC ne s’affiche pas en thème sombre et qt5ct ne s’ouvre tout simplement pas. En revanche, ils se lancent correctement et avec le bon thème si je les lance depuis un terminal…
 
J’ai regardé, j’ai a priori aucun paquet lié à Qt5 qui a été mis à jour aujourd’hui sur mon ordi.
 

J'ai eu pareil ce matin, ça fait bizarre, surtout que toutes les recherches que je faisait parlaient de pan_tally2 qui n'est plus inclu dans les versions de PAM

Perso ce que j'ai fait c'est modifier /etc/pam.d/system_auth (pas certain du nom exact du fichier), supprimer toute référence à pam_tally2.so et modifier les lignes parlant de pam_faillock.so pour ajouter "deny=5" et un timeout de 30s au lieu des 10 minutes

Si tu te retrouve bloqué en dehors de la session, tu peux utiliser "$ faillock --reset --user <login>" pour remettre le compteur à 0

EDIT : C'est le passage à PAM 14.0 qui pose problème
EDIT2: /etc/pam.d/system-auth (avec un tiret et pas un underscore)

Merci pour la remontée de ces bugs,

personnellement je n'ai pas fait de "pacman -Syu" depuis 2 semaines, du coup là je me demande si je dois attendre la résolution de ces 2 bugs avant de faire la mise à jour ?

Elbarto : je dirais que tu devrais au moins ignorer les MAJ de pam et de pambase, parce que je vois que ces deux-là pour mettre le bronx (y compris pour l’affichage des applis Qt5 ?) parmi les paquets que j’ai mis à jour ce jeudi.
Cela étant, de mon côté, je me sens pas de les rétrograder à la version antérieure (des fois que ça fasse conflit avec les fichiers de configuration existants, et j’ai pas envie de démarrer en chroot depuis un live pour arranger éventuellement ça de l’extérieur si je devais me foirer), donc je vais voir comment ça évolue. J’ai les liens ici et une alerte e-mail pour le bugtracker.
 
n0m1s : aucune référence à pam_tally de mon côté. Il devait déjà avoir dégagé quand j’ai installé Arch en 2016, ou j’ai rien installé qui l’aurait rajouté.
Pour le « deny » et autres délais de faillock, c’est pas plutôt le fichier « /etc/security/faillock.conf » qu’il faut modifier ? Ou les réglages (tous commentés) de ce dernier sont outrepassés par « /etc/pam.d/system_auth », donc ça n’a aucune importance de le faire sur l’un ou l’autre ?

Ce bug a été remonté y a plus de 2 semaines sur testing.
Je comprends pas qu'ils aient poussé pam hors de testing...

Un rapport de bug intéressant ici :
https://bugs.archlinux.org/task/676 [...] &sort=desc
 
ça peut toucher aussi le gestionnaire de connexion de session plasma SDDM.
 
Un bug qui semble très critique car certains ont leur PC complètement bloqué (impossible d'ouvrir sa session).
La prudence est donc d'exclure de la mise à jour les paquets pam et pambase (via l'option --ignore de pacman) tant que ces bugs ne sont pas résolus.
 
J'ai aussi la mention pam_tally dans ma config :
 

Oui il y a un truc qui a merdé, peut-être les vacances d'été, moins de vigilance chez les mainteneurs archlinux,

il n'y a même pas de warning, de message d'alerte dans la page d'accueil du site linux sur ce problème.

Une solution serait donc de supprimer (ou commenter) les lignes faisant réference à  pam_tally2 et pam_tally dans le fichier /etc/pam.d/system-login.
 
Il semblerait aussi que des fichiers *.pacnew soient crées, il faut alors regarder ce qu'il y a dedans pour mettre à jour son fichier de configuration de pam.
 

 
C'est le genre de choses qu'on oublie de faire, dans les autres distributions linux la mise à jour des fichiers de configuration est faite automatiquement (debian, ubuntu).

Je n'ai ni le problème ici, ni les divers fichiers pam en question.
 
Est-ce que ceux qui ont le soucis ont l'un d'eux? ( $HOME/.pam_environment otherwise it should be in /etc/security/pam_env.conf or /etc/environment) Enfin j'ai bien sur les 2 derniers, mais le 1er est entièrement commenté et le second n'a rien pour pam.
 
Meme question pour les pacsave/pacnew, aucun ici. pacdiff est utile pour ce genre de choses.

Je n'ai pas de fichier $HOME/.pam_environment, ni de fichier /etc/environment,

par contre j'ai bien un fichier /etc/security/pam_env.conf, à l'intérieur toutes les lignes sont commentées.

Mon installation d'archlinux date de novembre 2013, à l'époque les fichiers pam_tally2.so et pam_tally.so étaient peut-être requis par les paquets de l'époque.

Ah je n'ai pas de tally dans mes fichiers de conf, mais mon install est plus récente je crois. Je ne sais pas comment savoir la date (j'ai viré pacman.log en Janvier par accident :'/ ).

Mon installe date de septembre 2017 et j'avais quand même les références à tally2 dans mes réglages  
Je ne me souvient pas l'avoir modifié moi-meme, mais ça aurait du sens que ça ait pu être modifié en fonction du DE ou de la manière d'installer l'OS (je l'avait installé à la main, peut-être qu'Anarchy ou autre change ces réglages par défaut

En tout cas de mon coté je n'ai pas eu exactement le même problème que toi. J'ai uniquement été bloqué parce que j'ai loupé 3 fois mon MDP avec i3lock (ce qui m'arrive relativement souvent, merci le MDP long ) et pam_faillock m'a bloqué mon compte alors qu'avant la MàJ pam_tally2 ne bloquait pas le compte avec les écrans de lock

Lorsque j'ai regardé pour modifier tout ça, je n'ai pas lu quoi que ce soit qui mentionnait /etc/security/faillock.conf mais peut-etre que les réglages peuvent s'y fairent sans soucis, je n'en sais rien

Perso j'ai fichier ~/.pam_environment, oui. Mais je ne sais pas si ça influe sur le problème.

Pour les pacnew, j'en avais 2 dans /etc/pam.d : system_auth et lightdm. Les lignes "pam_tally2" étaient enlevées dans les pacnew

Je résume à nouveau : aucun .pam_environment dans ~, aucun fichier faisant référence à un quelconque « tally » (la commande grep m’a directement renvoyé sur un nouveau prompt), aucun *.pac{save,new} nulle part concernant dans /etc/{security,pam.d}.
 
/etc/environment ne contient que ça :
 

Et c’est là que je me dis que c’est à cause de cette version bugguée de pam que les applis Qt5 (sur lesquelles je force le thème « gtk2 » dans qt5ct pour rester raccord avec le thème GTK que j’utilise), ne tiennent plus compte de cette variable si je ne les lance pas depuis une invite de commandes. A fortiori, parce que ça déconnait pas avant cette MAJ de pam et qu’hier, aucun paquet ayant le moindre rapport avec Qt5 n’a été installé/mis à jour (y en avait que 3 ou 4, je les ai tous passés en revue dans la page « Packages » pour voir ce qu’ils étaient/faisaient).

Par acquis de conscience, j'ai été vérifier /etc/security/faillock.conf (que je n'avais vu mentionné nul part avant que tu en parles) et les réglages de faillock sont en effet modifiables là, en plus de pouvoir être modifiables dans /etc/pam.d/system-auth (qui outrepasse faillock.conf visiblement).
 
En tout cas merci pour l'info, j'ai finalement fait le paramétrage dans faillock.conf, c'est plus propre que dans system-auth

Forcément, vu que maintenant, il y a un fichier dédié pour ce genre de cas.
 

… où on y lit que downgrader (en tout cas, sans passer par un média live) est une très mauvaise idée :
 

OK, comme je ne l’avais pas sous la main de toute la semaine, je viens donc tout juste de faire la MAJ du PC fixe sous Arch, en ignorant explicitement pam et pambase. Résultat ? VLC et Notepadqq (en tant qu’exemples de logiciels Qt5) s’affiche avec le bon thème commandé par qt5ct. Comme c’est la seule différence entre le fixe et le portable, je pense qu’on peut confirmer que c’est bien cette MAJ de pam et pambase qui met aussi le b××del sur les logiciels Qt5…

Maintenant, reste à faire passer cette info aux mainteneurs d’Arch, sachant que le forum n’a jamais voulu me permettre de m’inscrire dessus (la question de validation échoue tout le temps, alors que je donne bien la bonne info)…

Essaie de t'inscrire sur le forum archlinux avec un autre navigateur (chromium, opera), c'est peut-être ton navigateur qui bogue sur certaines commandes javascript, ou un bloqueur de pub trop agressif ?
 
Sinon je viens de faire la mise à jour :
- les mentions "tally" ont disparu automatiquement de mon fichier de configuration de pam, et pas de fichier *.pacnew
 
par contre il y a un nouveau bug, relatif à kmix (une application kde pour le contrôle de volume), il y a maintenant un message d'erreur dans dmesg à propos de kmixctrl :
 

 
l'icône volume est pourtant présent et semble fonctionner malgré tout.
 

Pour déclencher le bug :
- ouvrez une console
- tapez "kmixctrl"

à la fin vous verrez le message "erreur de segmentation"

le backtrace avec le débogueur gdb :

EURÊKA !!!
 
J’ai enfin réussi à résoudre mon problème de session bloquée suite à la MAJ de pam ! Et dans la foulée, ça m’a aussi résolu le problème d’applications Qt5 (VLC et Notepadqq, notamment, mais aussi le panneau de paramètres Qt5 qui ne se lançait plus si ce n’était pas depuis un terminal) ! Ah, je suis heureux !
 
La solution est donc, dans le fichier « /etc/security/faillock.conf », de changer la ligne « # deny = 3 » en « deny = 0 ». Et là, tout refonctionne comme avant !
 
Merci à nl6720 sur le bugtracker d’Arch Linux : https://bugs.archlinux.org/task/67644#comment192042 !!!

J'allais faire comme vous et changer deny = 3, mais je me dis que si jamais j'oublie un faillock.conf.pacsave un mauvais jour ca pourrait m’embêter donc je ne sais pas trop quoi faire...
 
C'est ce qui est pratique avec les override.conf de systemd on rajoute un autre fichier pour juste la modif qu'on veut et c'est tout, pas de .pacsave/pacnew a gérer.
 
Sinon c'est bizarre en effet que cela suffise pour les application Qt, je suis curieux de voir l'explication si quelqu'un en trouve une un jour.

C’est effectivement un risque, mais bon, faudra faire gaffe et ne pas faire la MAJ comme ça, sans avoir au moins regardé le contenu des paquets.
 

Je saurais pas dire, mais peut-être que lors de leur lancement (du moins, depuis un raccourci), ces applications procèdent à une sorte d’identification en arrière-plan via qt5ct (parce que lui, il se lançait pas du tout, depuis un raccourci, contrairement aux autres qui reprenaient le thème Fusion par défaut) ? Et qu’à cause de ce mauvais réglage de pam, ça échouait et donc, ça revenait aux paramètres d’affichage par défaut ? Je vois pas bien trop pourquoi ce serait comme ça, mais de ce qu’on peut constater, il y a forcément un truc de ce genre, pour aussi absurde et incongru que ça puisse paraître. Parce que oui, je le redis, pour qu’un simple changement dans la config de pam ait des répercussions sur l’affichage de logiciels Qt5, c’est qu’il y a forcément un lien entre les deux, quelque part. Il existe, on peut pas le nier, sinon les choses n’auraient pas pu se passer telles que je les ai vues et décrites.
 
Bizarrement, j’avais aussi un autre logiciel (Karaokes Mugen, pour ne pas le nommer : une appli NodeJS et Electron, qui dépend aussi de Yarn et de PostgreSQL pour sa base de données) qui échouait à se connecter à sa base de données PostgreSQL, alors que le service concerné était bien démarré. Même le dev en chef du logiciel ne savait pas pourquoi ça ne fonctionnait pas quand je lui ai envoyé le log des messages d’erreur. J’ose espérer que, maintenant, c’est aussi résolu (je n’ai pas encore testé).

 
Certains ont-ils détecté un problème avec la dernière version de Chromium ?
 
De mon côté j'ai des bugs d'affichage sur cette version (85.0.4183.83, build officiel des dépots), quand je déplace la souris sur la barre d'url ou même sur les pages de certains sites, ça clignote à certain endroits ...
Aucun souci avec d'autres applis ...
 
KDE plasma 5.19.4

J'ai pas l'air d'avoir ce problème perso (même version de chromium, mais sous xfce)

J'ai encore l'ancienne version de chromium (84.0.4147.135), car je mets à jour mon système qu'une fois par semaine, pas de soucis graphique avec cette version.

Celle dont parle Minux est sortie qu'hier. il faudrait voir si en downgradant le paquet le problème disparaît.

Peut-être un souci de pilote graphique chez lui, surtout s'il utilise un pilote propriétaire, mais le problème devrait alors se produire aussi avec les autres applications.
Si c'est pas ça alors peut-être suspecter un problème de miroir pas à jour, des bibliothèques attendues par chromium qui auraient dû être à une version N, mais qui sont chez Minux à une version N-1 si son miroir n'est pas à jour, ou qu'il utilise un panachage de miroirs dans son fichier de configuration.