Reprise du message précédent :
Mon écran est uniquement en 60 hz donc je ne pourrais pas te répondre.

Ha ben je me suis souvenu pourquoi j'avais viré xfce.
A chaque fois que l'écran se met en veille, l'écran repasse en 60Hz en sortie de veille !
C'est dingue je l'ai senti direct que j'étais en 60hz....
Je me disais c'est bien xfce4 pourquoi j'avais changé ?
Ils ont toujours pas corrigé ce bug.....
Et du coup mate fonctionne de nouveau !
Étrange tout ça

Bon, je confirme que mon problème d'accent circonflexe vient de la version "Fresh" de Libreoffice, en repassant en "Still" il disparaît.

Très étrange, car je l’ai dit : je suis aussi en Fresh et j’ai pas du tout ce souci d’accent circonflexe… Ça le fait dans un module particulier, une police particulière, ou tout le temps et avec n’importe quelle police ?
 
Avec un profil de LibO vierge, ça le fait aussi (renomme le dossier « ~/.config/libreoffice ») ?

un bug dans firefox 66 sous archlinux (et peut-être sous windows) :
 
- certains sites affichent par défaut la version anglaise des pages pour les menus, les boutons (par exemple un bouton qui porte le nom "submit" au lieu de "valider" ),
 
et ce malgré la configuration de langue sur "french [fr-fr]" dans les préférences de firefox pour la langue à utiliser pour les sites qui sont multi-langues

pour reproduire le bug :

- créez ce fichier de test html :

- ouvrez le fichier html sous firefox 66, vous remarquerez que sous firefox 66 le bouton de validation porte le nom de "submit" au lieu de "valider"

- si vous ouvrez le fichier avec chromium ou opera vous remarquerez que le bouton de validation porte cette fois le nom "valider" (la langue française est bien appliquée)

ça semble être un bug du paquet archlinux de firefox 66,  
car si j'utilise le binaire officiel disponible sur le site de firefox alors pas de soucis :
 
https://www.mozilla.org/fr/firefox/new/

le problème semble se produire à chaque fois que firefox est mis à jour via "pacman -Syu", lors du premier lancement après la mise à jour firefox se met en anglais (pas pour les menus de l'application, mais uniquement les boutons et la langue des pages web),
parfois firefox se remet automatiquement en français pour les pages web lorsqu'on le ferme et qu'on le relance,

et on peut tenter de corriger le problème en allant dans les préférences de firefox, rubrique "général", puis "langues", vous verrez alors une interface pas très ergonomique, qui permet de choisir la langue de firefox et celle des pages web,
on remarque qu'il y a 3 possibilités ("french", "france [fr]",et "france [fr-fr]" ), et 3 moyens de configurer la langue : via une liste déroulante,  via le bouton "choisir des alternatives" et un autre bouton "choisir"

Je sais pas si elle est toujours utile, mais dans « about:config », est-ce que la clef « general.useragent.locale » est bien réglée sur « fr-FR », chez toi ? Par défaut, sur (Arch ?) Linux, même avec le paquet « firefox-i18n-fr » installé, elle est réglée sur « en-US »…
 
Et évidemment, la clef « intl.locale.requested » est, elle aussi, réglée sur « fr » ? Elle n’est pas créée par défaut, donc si elle n’existe pas, crée-la manuellement.

Je suis en bêta et je n'avais pas remarqué ce problème.
Pour info c'est "firefox-beta-bin-all-localizations" (AUR) et il y a un petit fichier de configuration à créer pour avoir la bonne langue.
Pas de bug en tous cas avec la v67.0b4

 
la clé "general.useragent.locale" n'existe pas chez moi,
 
et "intl.locale.requested" a comme valeur aucune chaine, c'est vide

OK, donc tu confirmes un de mes doutes, par la même occasion : la première clef a été remplacée par la deuxième dans Firefox 59. Donc, tu peux l’oublier.
 
En revanche, il faut bien que « intl.locale.requested » ait « fr » comme valeur pour être sûr que Firefox est bien correctement francisé.

tu as quoi exactement comme valeur pour la clé intl.locale.requested ?

"fr" ou "fr-FR" ?

Je pense que les deux doivent donner plus ou moins le même résultat. Mais chez moi, c’est juste « fr ».

la loose, je n'ai plus de réseau, pas de wifi. Plus d’icônes, rien, si je coupe le wifi avec le bouton et que je le remets, il ne se passe rien, le témoin lumineux wifi reste éteint même. (portable Dell Latitude E6520).

Je n'ai pas bien chercher encore, mais a priori il y a eu une maj de "networkmanager" hier.

edit : je ne sais pas si cela à un rapport mais j'ai :

edit 2 : j'ai fait une mise à jour par ethernet.
j'ai réussi à lancer networkmanager manuellement, l’icône apparait et le pc se connecte alors bien au wifi.

edit 3 : hop c'est reglé ! J'avoue que hier je me suis dit "tiens ! ça y est ça part en cou*lle, j'ai un gros soucis" mais finalement les mises à jour ont corrigé le tir assez vite. c'est cool Arch

 , je ne sais pas si c'est le noyau 5.0.4 ou bien le gros nettoyage niveau disque dur (j'ai tout débranché sauf le SSD) mais ça démarre vachement mieux:

Je dois avouer ne pas avoir retenté de redémarrer sur le noyau 5.x depuis la mise en place du noyau LTS sur ce PC… Mais si ce souci est enfin corrigé, c’est tant mieux ! Je verrai à l’occasion, un jour où je pourrai perdre cinq minutes à faire un redémarrage de test…

tu peux tenter de créer une clé USB bootable contenant la dernière image iso d'installation d'archlinux,

si elle a le noyau 5.0.4 et que ça démarre vite sur ce pc alors c'est bon signe

Zut, j’ai flingué le message d’avant… J’ai essayé de le reconstituer au mieux, pardon.
 

Bon, ben j’ai profité de la mise à jour du noyau LTS pour redémarrer sur le 5.0.4, et… c’est toujours pareil : 32,762 secondes de démarrage en kernel, contre seulement 16,466 s en userspace…
 
À tout hasard, j’ai regardé les données SMART du plus vieux des deux disques (vendu avec la machine, donc a fêté ses 10 ans il y a peu) :
 

Si tu me dis que ce serait à cause de lui, je serai peut-être disposé à te croire (mais pourquoi est-ce que ça ne gêne pas le démarrage du noyau LTS, alors ?)…

ton disque semble en bonne santé, pas de secteurs ré-alloués, juste la mention d'un secteur un peu instable (197 Current_Pending_Sector : 1),

il faudrait tester en désactivant dans le bios la carte son, la carte réseau, pour voir si le noyau démarre plus vite, si oui alors c'est peut-être le pilote d'un de ces composants qui est bogué dans la version 5.x du noyau,

il y a aussi un paramètre "debug" à passer au boot pour le noyau, afin que dmesg affiche plus d'infos, ça peut t'aider à identifier la cause du problème :

https://wiki.archlinux.org/index.ph [...] meter_list

LOL nvidia : https://bugs.archlinux.org/task/62258
 
quand on installe CUDA, il faut avoir /bin dans le $PATH, et déclarer la variable $LD_LIBRARY_PATH qui pointe vers /lib64. Jusque là rien de grave
Sauf que ces couillons, ils ont hardcodé le chemin de CUDA dans le Makefile, du coup si tu installes pas CUDA dans le chemin standard (ce qui est le cas avec le package Arch), ben les examples ne compilent jamais.

 
 
Pour l'instant je teste dans une VM. Je me débrouille pour un débutant sur Linux, surtout habitué à Debian et dérivés. Le paradigme d'Arch est vraiment intéressant et surtout très formateur je trouve.

Je confirme, après des années sur Ubuntu, j'ai appris beaucoup plus de choses sur linux en une installation d'Arch

Pareil, mais après un an il m'en reste pas grand chose...

j'ai parfois ce bug au boot, qui arrive dans 5 à 10% des boots, un bug non bloquant , ça doit faire au moins un an qu'il existe :
 
https://bugs.archlinux.org/task/54343
 
visible dans dmesg :
 

 
C'est le plus grand défaut de Arch ; stable malgré les paquets à jours d'un coup on à tendance à oublier les commandes de base vu qu’il y à rien à dépanner

J'attends toujours la grosse panne qui va me faire planter le système... ça commence à faire long  

C’est un troll de debianeux ou d’ubuntistes qui n’arrivent pas à admettre qu’une RR puisse tenir sur la durée sans nécessiter la moindre réinstallation tant que le matériel ne tombe pas en panne ; et même durer plus longtemps que leurs OS chéris qu’ils doivent, eux, réinstaller tous les 6 mois ou 2 ans parce que ce sont les MAJ qui les cassent. Bref, des jaloux, quoi.  
 
Sinon, si tu y tiens, tu as Manjaro qui nous a fait deux belles MAJ foireuses en un an et demi (avril 2017 : une MAJ qui cassait X.org si faite en graphique ; et une autre fin 2018 qui empêchait carrément le démarrage de la distribution, si je me souviens bien). Du côte d’Arch, la dernière fois qu’une MAJ a nécessité une manipulation particulière, c’était en juillet dernier et ça consistait basiquement à supprimer préalablement un fichier avant, ou forcer son écrasement avec un paramètre qu’il est généralement déconseillé d’utiliser (--force) car lui, il peut casser la distro.

+1 avec Trit', en presque 10 ans d'Arch, je l'ai réinstallé qu'une fois, suite à panne du disque sur lequel la distri était installée ... Et pourtant j'ai changé pas mal de fois de carte mère (+ proc certaines fois), carte graphique (dont certaines fois switch AMD <-> Nvidia) et carte son, et j'ai jamais eu besoin de réinstall la distrib  

J'en ai planté 2 d'affilées avec le noyau 4.18 ou 4.28, je ne sais même plus.

 
J'utilise les deux au quotidien ( Ubuntu sur mes 2 PC portables et Arch sur le PC fixe ) et j'aime bien les 2 systèmes    
Ubuntu Mate frôle la perfection sur mon PC portable Lenovo, et je n'ai donc aucunement envie de le remplacer  

Ben oui mais à la prochaine mise à jour qui va péter ton ubuntu tu fais comment ?

ce qui peut faire planter arch linux :

1) le recours excessif aux paquets du dépôt aur, ça augmente le risque de problèmes, surtout si l'auteur du paquet a de mauvaises intentions ou ne respecte pas les standards de qualité en terme d'empaquetage

2) une défaillance des bêta-testeurs, ou un nombre insuffisant de testeurs, ou encore le packageur archlinux qui ne teste jamais ce qu'il produit, ce qui fait qu'un paquet de mauvaise qualité, bogué peut arriver dans les dépôts officiels stables

3) l'utilisateur qui cherche trop la nouveauté, un peu trop naif/confiant, qui teste des trucs "hype" à la "wayland", la version "fresh" de libreoffice, qui fait des "pacman -Syu" toutes les 2 heures comme un ouf

4) l'utilisation de pilotes propriétaires (carte graphique, type nvidia), ça ne fait pas toujours bon ménage avec une distribution rolling release

5) certains défauts de l'outil pacman, le cas des fichiers *.pacnew, *.pacsave, pas d'option "--rollback" pour annuler le dernier "pacman -Syu" qui aurait introduit un bug (obligation de traquer à la main le paquet coupable et de le downgrader, parfois via un chroot),
les messages "info/notice" de pacman à peine lisibles, noyés dans la sortie console quand il y a une centaine de paquets à mettre à jour

La version « Fresh » de LibreOffice est une version finalisée, hein ! C’est d’ailleurs la seule version considérée comme officielle (« Still » est plutôt à voir comme une équivalente d’une « oldstable » pour Debian : version en fin de vie car remplacée par une nouvelle, et qui n’aura plus que des correctifs de sécurité), au sens où quand TDF annonce la sortie d’une nouvelle version majeure (6.0, 6.1, 6.2…), ça s’applique à la version de la branche « Évolution » (donc Fresh), pas à la « Stable » (Still).
Le seul truc, c’est qu’ils conseillent d’attendre la sous-version .3 ou .4 pour passer de Still à Fresh dans les milieux professionnels.

Fresh c'est nul, ça supporte pas les accents circonflexes.

(j'ai vraiment eu ce problème, cf. mes anciens posts )

J'ai un soucis sur ma archlinux depuis 3 semaines.
(Je crois que c'est depuis le noyau 5 mais pas sûr)

On dirai que le ventilo de ma carte graphique n'est plus régulé.
du coup quand je joue longtemps ça fini par crash.
Par contre c'est silencieux mais bon....

Alors que sous windows pas de souci, quand je joue j'entends bien le ventilateur accélérer et pas de crash.

Et là je ne sais pas quoi faire !

Il existe un logiciel pour réguler les ventilos (sur Aur). C'est assez "dangereux" mais vu que tu es dans la DANGER ZONE (référence culturelle. ), tu ne risques rien de plus.
https://aur.archlinux.org/packages/radeon-profile-git

Woa merci beaucoup je vais essayer.
T'inquiète pour le danger avec AUR je crois j'ai déjà pas mal d'expérience même les pires

Bon ben je peux pas réguler ni oc c'est grisé....
J'ai cru lire qu'il y a un bit d'overclocking à activer dans grub.....
Font chier linux défois.

Quelqu'un sous KDE Plasma pourrait me dire si la console affiche quelque chose après avoir tapé la commande :
 
sddm-greeter --test-mode --theme /forumhfr
 
Ça permet de prévisualiser des thèmes pour sddm et normalement d'afficher le log de debug à la suite dans la console mais j'ai pas le debug et je sais pas si cela viens d'un réglage chez moi ou de la distri..  
d'un coup je suis obliger d'utiliser une VM pour faire ça car je trouve pas l'origine pour l'activer... :x
 
Si ça viens de mon ordi je me rappel avoir désactiver des warnings qui spammaient mon journal en lançant un petit utilitaire graphique de plasma accessible via une ligne de commande mais je retrouve plus du tout c'était quoi cette commande pour vérifier si ça à un rapport..  
(ça ouvrait une petite fenêtre toute pourri et on pouvais décocher des choses à ne pas loguer mais c'est pas lié à l'appli Ksystemlog si ça parle à quelqu'un )

Les logs ne semblent pas désactivés dans le PKGBUILD, le fichier conf n'a pas de référence à ça, pas d'infos dans les issues de github ou dans les wiki, bref ça marche dans toutes mes VM sauf que c'est pas pratique du tous vu que c'est pas là que je dev